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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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Scope 



The present document provides the protocol details for conferencing within the IP Multimedia Core Network subsystem 
(IMS) based on the Session Initiation Protocol (SIP), SIP Events, the Session Description Protocol (SDP) and the 
Binary Floor Control Protocol (BFCP). 

The functionalities for conference policy control (with respective standardised protocols) are felt to be essential for a 
complete IMS conferencing service but are not specified in this version of IMS conferencing and are for further study. 

The present document does not cover the signalling between a MRFC and a MRFP. 

Where possible, the present document specifies the requirements for this protocol by reference to specifications 
produced by the IETF within the scope of SIP, SIP Events, SDP and BFCP, either directly, or as modified by 
3GPP TS 24.229. Where this is not possible, extensions to SIP are defined within the present document. The document 
has therefore been structured in order to allow both forms of specification. 

The present document is applicable to Application Servers (ASs), Multimedia Resource Function Controllers (MRFCs), 
Multimedia Resource Function Processors (MRFP), Media Gateway Control Functions (MGCFs) and to User 
Equipment (UE) providing conferencing capabilities. 
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3 Definitions, symbols and abbreviations 

3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 21.905 [1], and the following 
apply: 

Conferencing AS: an Application Server that supports functionality specific to a SIP conference focus 

Ad-hoc conference: An unscheduled conference that is created on-the-fly by a conference participant. 

The following terms and definitions given in 3GPP TS 23.228 [2] apply (unless otherwise specified): 

Public Service Identity 
Three-way session 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7] 
subclauses 4.3.3.1 and 4.6 apply: 

IP-Connectivity Access Network (IP-CAN) 

The following terms and definitions given in RFC 4353 [8] apply (unless otherwise specified): 

Conference 

Conference-Aware Participant 

Conference notification service 

Conference Policy 

Conference-Unaware Participant 

Conference URI 

Focus 

Mixer 

Participant 

Tightly Coupled Conference 

The following terms and definitions given in RFC 4579 [9] apply (unless otherwise specified): 

Conference Factory URI 
For the purposes of the present document, the following terms and definitions given in RFC 3840 [19] apply: 

Feature parameter 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.002 [2] 
subclauses 4.1.1.1 and 4a.7 apply: 

Call Session Control Function (CSCF) 

Home Subscriber Server (HSS) 

Media Gateway Control Function (MGCF) 

Multimedia Resource Function Controller (MRFC) 

Multimedia Resource Function Processor (MRFP) 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.218 [5] 
subclause 3.1 apply: 

Filter criteria 
Initial filter criteria 
Initial request 
Subsequent request 

For the purposes of the present document, the following terms and definitions given in 3GPP TS 23.228 [7] 
subclauses 4.3.3.1 and 4.6 apply: 

Interrogating-CSCF (I-CSCF) 
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Proxy-CSCF (P-CSCF) 
Public user identity 
Serving-CSCF (S-CSCF) 

For the purposes of the present document, the following terms and definitions given in 3GPP TR 21.905 [1] apply: 

User Equipment (UE) 

For the purposes of the present document, the following terms and definitions given in RFC 4582 [28] apply: 

Floor 

Floor chair 
Floor control server 
Floor participant 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AMR Adaptive Multi-Rate 

AS Application Server 

BFCP Binary Floor Control Protocol 

CN Core Network 

CSCF Call Session Control Function 

FQDN Fully Qualified Domain Name 

HSS Home Subscriber Server 

I-CSCF Interrogating CSCF 

IM IP Multimedia 

IMS IP Multimedia CN subsystem 

IP Internet Protocol 

IP -CAN IP-Connectivity Access Network 

MGCF Media Gateway Control Function 

MRFC Multimedia Resource Function Controller 

MRFP Multimedia Resource Function Processor 

P-CSCF Proxy CSCF 

PSI Public Service Identity 

S-CSCF Serving CSCF 

SDP Session Description Protocol 

SIP Session Initiation Protocol 

TLS Transport Layer Security 

UE User Equipment 



Conferencing overview 



The basic services for the IP Multimedia core network Subsystem (IMS), as defined in 3GPP TS 24.229 [5], allow a 
user to initiate, modify and terminate media sessions based on the Session Initiation Protocol, as defined in 
RFC 3261 [7]. Although these basic mechanisms already allow multi party calls, more sophisticated services for 
communication between multiple parties can be made available by the network. 

The conferencing service provides the means for a user to create, manage, terminate, join and leave conferences. It also 
provides the network with the ability to give information about these conferences to the involved parties. 

The network operator or the user may apply membership and media policies to a conference. The functionality for 
conference policy control (with a respective standardised protocol) is felt to be essential for a complete IMS 
conferencing service but is not specified in this version of IMS conferencing and is for further study. 

Conferencing applies to any kind of media stream by which users may want to communicate, this includes e.g. audio 
and video media streams as well as instant message based conferences or gaming. Floor control, as part of the 
conferencing service offers control of shared conference resources at the MRFP using BFCP. 

The framework for SIP conferences is specified in RFC 4353 [8]. 
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The architecture for the 3GPP conference service is specified in 3GPP TS 23.228 [6] and 3GPP TS 23.218 [3]. 

The present document specifies the usage of SIP, SDP and BFCP to reaUze 3GPP conference service based on the 
protocols specified by the IETF defined conference service as per RFCs listed in clause 2. However, since the IETF 
conference service has various scenarios and features as described in RFC 4353 [8], 3GPP conference service is a 
subset of the above IETF defined conference service. 

Loosely coupled conferencing is outside the scope of this release of the IMS conferencing service. 

The following figure depicts the functional split for SIP based conferences between the AS, the MRFC and the MRFP. 




MRFP 



Mixer 



a- 



Floor Control 
Server 



-^ 



RIP / RTCP 



BFCP 



Figure 4.1 : Functional split between the AS, MRFC and MRFP 

The conference policy, conference notification server and top-level focus as specified in RFC 4352 [8] subclause 6 are 
located in the AS. 

The MRFC has a conference policy and focus as specified in RFC 4352 [8] subclause 6.3. 

The mixer and floor control server are located in the MRFP. 



£75/ 



3GPP TS 24.147 version 10.2.0 Release 10 12 ETSI TS 124 147 V10.2.0 (2012-01) 

5 Protocol using SIP and SIP events for conferencing 

5.1 Introduction 

Void 

5.2 Functional entities 

5.2.1 User Equipment (UE) 

For the purpose of SIP based conferences, the UE shall implement the role of a Conference participant as described in 
subclause 5.3.1. 

5.2.2 Media Resource Function Controller (MRFC) 

For the purpose of SIP based conferences, the MRFC shall support the procedures for ad-hoc conferencing as described 
in subclause 5.8 of 3GPP TS 24.229 [5] and the procedures for media control of ad-hoc conferencing described in 
subclause 10.3 of 3GPP TS 24.229 [5] 

For the purpose of SIP based conferences, the MRFC shall regard the MRFP as a mixer, as described in RFC 4353 [8]. 

5.2.3 Conferencing Application Server (AS) 

For the purpose of SIP based conferences, the conferencing AS shall implement the role of a conference focus, as 
described in subclause 5.3.2 and as a conference notification service, as described in subclause 5.3.3. The conferencing 
AS may implement the role of a conference participant as described in subclause 5.3.1. 

The conferencing AS shall use the procedures for 3"* party call control as described in subclause 5.7.5 of 

3GPP TS 24.229 [5] and the procedures for media control in subclause 10.2 of 3GPP TS 24.229 [5] to implement SIP 

based conferences. 

5.2.4 Media Gateway Control Function (MGCF) 

For the purpose of SIP based conferences, the MGCF shall implement the role of Conference participant as described in 
subclauses 5.3.1.3.2, 5.3.1.4.1, 5.3.1.5.4, 5.3.1.6.1 and 5.3.1.6.2. In addition, MGCF shall implement the functions 
except the "REFER" function in subclause 5.3.1.3.3. 

5.3 Role 

5.3.1 Conference Participant 

5.3.1.1 General 

In addition to the procedures specified in subclause 5.3.1, the conference participant shall support the procedures 
specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the conference participant is implemented. 

5.3.1 .2 Subscription for conference event package 

The conference participant may subscribeto the conference event package, as described in RFC 4575 [11]. 
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5.3.1 .3 Conference creation 

5.3.1.3.1 General 

A conference can be created by means of SIP, as described in subclause 5.3.1.3.2 or subclause 5.3.1.3.3. 

NOTE: Additionally, creation of a conference can be provided by other means. 

The conference participant shall make use of the procedures for session establishment as described in subclauses 5. 1.2 A 
and 5.1.3 of 3GPP TS 24.229 [5] when creating conferences by means of SIP. 

5.3.1 .3.2 Conference creation with a conference factory URI 

Upon a request to create a conference with a conference factory URI, the conference participant shall: 

1) generate an initial INVITE request in accordance with subclause 5.1.3.1 of 3GPP TS 24.229 [5]; and 

2) set the request URI of the INVITE request to the conference factory URI. 

On receiving a 200 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact 
header, the conference participant shall store the content of the received Contact header as the conference URI. In 
addition to this, the conference participant may subscribe to the conference event package as described in 
RFC 4575 [1 1] by using the stored conference URI. 

NOTE 1 : A conference participant can decide not to subscribe to the conference event package for conferences with 
a large number of attendees, due to, e.g. the signalling traffic caused by the notifications about users 
joining or leaving the conference. 

NOTE 2: A conference can also be created with a conference URI. The procedures for this case at the conference 
participant are identical to those for joining a conference, as described in subclause 5.3.1.4.1. It is not 
assumed that the conference participant is aware that the conference gets created in this case. 

NOTE 3: The UE can discover the conference factory URI from the Management Object as defined in 

3GPP TS 24.166 [38]. Further discovery mechanisms for the conference factory URI are outside the 
scope of the present document. 

5.3.1 .3.3 Three-way session creation 

When a user is participating in two or more SIP sessions and wants to join together two of these active sessions to a so- 
called three-way session, the user shall perform the following steps. 

1) create a conference at the conference focus by sending an INVITE request with the conference factory URI for 
the three-way session towards the conference focus, as described in subclause 5.3.1.3.2; 

2) decide and perform for each of the active sessions that are requested to be joined to the three-way session, how 
the remote user shall be invited to the three-way session, which can either be: 

a) by performing the procedures for inviting a user to a conference by sending an REFER request to the user, as 
described in subclause 5.3.1.5.2; or 

b) by performing the procedures for inviting a user to a conference by sending a REFER request to the 
conference focus, as described in subclause 5.3.1.5.3; 

3) release the active session with the user, by applying the procedures for session release in accordance with 
RFC 3261 [7], provided that a BYE request has not already been received, after a NOTIFY request has been 
received, indicating that the user has successfully joined the three-way session, i.e. including: 

a) a body of content-type "message/sipfrag" that indicates a "200 OK" response; and, 

b) a Subscription-State header set to the value "terminated"; and, 

4) treat the created three-way session as a normal conference, i.e. the conference participant shall apply the 
applicable procedures of subclause 5.3.1 for it. 
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5.3.1.4 Joining a conference 

5.3.1 .4.1 User joining a conference by using a conference URI 

Upon generating an initial INVITE request to join a conference for which the conference URI is known to the 
conference participant, the conference participant shall: 

1) set the request URI of the INVITE request to the conference URI; and 

2) send the INVITE request towards the conferencing AS that is hosting the conference. 

NOTE 1: The initial INVITE request is generated in accordance with 3GPP TS 24.229 [5]. 

NOTE 2: The conference participants can get the conference URI as described in subclause 5.3.1.4.2. Other 

mechanisms can also be used by the conference participant to become aware of the conference URI, but 
they are out of scope of this specification.. 

On receiving a 200 (OK) response to the INVITE request with the "isfocus" feature parameter indicated in Contact 
header, the conference participant shall store the contents of the received Contact header as the conference URI. In 
addition to that, the conference participant may subscribe to the conference event package as described in 
RFC 4575 [1 1] by using the stored conference URI. 

NOTE 3: A conference participant can decide not to subscribe to the conference event package for conferences with 
a large number of attendees, due to the signalling traffic caused by the notifications about e.g. users 
joining or leaving the conference. 

Upon receipt of an INVITE request that includes a Replaces header, the conference participant shall apply the 
procedures described in RFC 3891 [33] to the INVITE request. 

5.3.1 .4.2 User joining a conference after receipt of a REFER request 

Upon receipt of a REFER request that either includes a Refer-To header which includes the "method" uri parameter set 
to INVITE or does not include the "method" URI parameter, the conference participant shall: 

1) handle the REFER request in accordance with RFC 3515 [17]; 

2) perform the actions as described in subclause 5.3.1.4.1 for a user joining a conference; and 

3) if the received REFER request included a Referred-By header, include the Referred-By header in accordance 
with RFC 3892 [20] in the INVITE request that is sent for joining the conference. 

5.3.1 .5 Inviting other users to a conference 
5.3.1.5.1 General 

Upon inviting other users to a conference, the conference participant has to decide which of the following procedures 
has to be applied: 

1) inviting an user to a conference by sending a REFER request to the user directly, as described in 

subclause 5.3.1.5.2; or 

2) inviting a user to a conference by sending a REFER request to the conference focus, as described in 
subclause 5.3.1.5.3; or 

3) inviting one or more users to a conference by adding these users" SIP URIs to the INVITE request that is sent to 
the Conference focus to create the conference (see subclause 5.3.1.3.2) as described in subclause 5.3.1.5.4. 

NOTE: Additionally, users can be invited to a conference by other means. 

It is out of the scope of the present document, how the UE decides which of the above procedures shall be applied. 
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5.3.1 .5.2 User invites other user to a conference by sending a REFER request to the other 
user 

Upon generating a REFER request that is destined to a user in order to invite that user to a specific conference, the 
conference participant shall: 

1) set the request URI of the REFER request to the address of the user who is invited to the conference; 

2) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall 
be invited to, including the "method" URI parameter set to "INVITE" or omit the "method" parameter; and 

NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5]. 

3) send the REFER request towards the user who is invited to the conference. 

The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference 
participant that is sending the REFER request. 

Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in 
accordance with RFC 3515 [17] and may indicate the received information to the user. 

5.3.1 .5.3 User invites other user to a conference by sending a REFER request to the 
conference focus 

Upon generating a REFER request that is destined to the conference focus in order to invite another user to a specific 
conference, the conference participant shall: 

1) set the request URI of the REFER request to the conference URI to which the user is invited to; 

2) set the Refer-To header of the REFER request to the SIP URI or tel URL of the user who is invited to the 
conference; 

3) either include the "method" URI parameter with the value "INVITE" or omit the "method" URI parameter in the 
Refer-To header; and 

NOTE: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5]. 

4) send the REFER request towards the conference focus that is hosting the conference. 

The UE may additionally include the Referred-By header to the REFER request and set it to the URI of the conference 
participant that is sending the REFER request. 

In case of an active session the UE may additionally include the Replaces header in the header portion of the SIP URI 
of the Refer-to header field of the REFER request. If the the user involved in the active session is identified by a tel 
URI, the UE shall convert the tel URI to an SIP URI as described in RFC 3261 [7] before including the Replaces header 
field. The included Replaces header field shall refer to the active dialog that is replaced by the ad-hoc conference. The 
Replaces header field shall comply with RFC 3891 [33]. 

Afterwards the UE shall treat incoming NOTIFY requests that are related to the previously sent REFER request in 
accordance with RFC 3515 [17] and may indicate the received information to the user. 

5.3.1 .5.4 User invites other users to a conference by including URI list in initial INVITE 
request to the conference focus 

Upon generating an INVITE request that is destined to the conference focus in order to create a conference using a 
conference factory URI (see subclause 5.3.1.3.2) the UE may attach a message body to the request that includes a URI 
list as described in RFC 5366 [34]. In order to do this the UE shall follow the procedures in subclause 5.3.1.3.2 for 
creation of the INVITE request and, in addition, the conference initiator shall build a list of URIs in accordance with 
RFC 5366 [34] including the SIP URIs of all the users that are to be invited to the conference. 

In case of an ad-hoc conference where the conference creator is already involved in a dialog with a user who shall be 
invited to the conference, the UE may add information of this dialog ID (Call-ID header field. From header field. To 
header field, and if available a Session-ID header field as described in draft-kaplan-sip-session-id [37]) to the URIs in 
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the URI list, according to the procedures for adding header fields ("?" mechanism) described in subclause 19.1.1 of 
RFC 3261 [7]. 

Once the INVITE request has been sent, the conference participant shall behave as described in subclause 5.3.1.3.2 
once the 200 (OK) response to the INVITE is received. 

5.3.1 .6 Leaving a conference 

5.3.1 .6.1 Conference participant leaving a conference 

When leaving a conference, the conference participant shall: 

1) generate a BYE request on the dialog that was established when joining or creating the conference, in 
accordance to the procedures described in 3GPP TS 24.229 [5] and RFC 3261 [7]; 

2) if the conference participant is subscribed to the conference state event information of that conference, the 
conference participant shall not renew this subscription and let the related subscription timer expire. When a 
related NOTIFY request is received which does not include a Subscription-State header set to the value 
"terminated", the conference participant shall: 

a) wait for an implementation dependant time, if a related NOTIFY request with the Subscription-State header 
set to the value "terminated" is received; and 

b) afterwards, if no such NOTIFY request is received, unsubscribe from the conference state event information 
by performing the procedures as described in RFC 3265 [10] and RFC 4575 [11]. 

NOTE 1 : A conference participant leaving a conference will cause the conference notification service to send a 

NOTIFY request with updated conference state information to all conference participants, including the 
participant who just left. Therefore the time between sending the BYE request and receiving the next 
NOTIFY request is very short. The conference participant does not immediately unsubscribe from the 
conference event package in order not to cause unnecessary traffic on the air interface. 

NOTE 2: After the conference participant leaves the conference, it can receive NOTIFY requests that cross the 
BYE request sent by the conference participant. In this case, the NOTIFY request will not include a 
Subscription-State header with the value "terminated", as it was issued before the conference focus / 
conference notification service got aware of the conference participant leaving the conference. Due to this 
another NOTIFY request may be received within a short period of time (see NOTE 1), that carries the 
Subscription- State header set to "terminated". 

5.3.1 .6.2 Conference focus removes conference participant from a conference 

Upon receipt of a BYE request on the dialog that was established when joining or creating a conference, the conference 
participant shall: 

1) respond to the BYE request as described in 3GPP TS 24.229 [5] and RFC 3261 [7]; and 

2) if the conference participant is subscribed to the conference state event information of that conference, perform 
the actions for not renewing the subscription to the conference state event information as described for the 
conference participant leaving a conference in subclause 5.3.1.6.1. 

5.3.1 .6.3 Removing a conference participant from a conference 

Upon generating a REFER request to remove a conference participant from a conference, the removing conference 
participant shall: 

1) set the request URI of the REFER request to the conference URI of the conference from which the conference 
participant shall be removed 

2) set the Refer-To header of the REFER request: 

a) to the address of the conference participant who should be removed from the conference, including the 
"method" parameter set to "BYE', if a single conference participant should be removed from the conference. 
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If the address of conference participant is a global tel URI, it shall be converted to SIP URI as described in 
RFC 3261 [7]; or 

b) to the conference URI and the 'method" parameter to 'BYE', if all conference participants shall be removed 
from the conference. 

NOTE 1: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5]. 

NOTE 2: The removal of all conference participants from the conference will terminate the conference if the 
conference policy is set accordingly. 

3) send the REFER request towards the conference focus that is hosting the conference. 

Afterwards the removing conference participant shall treat incoming NOTIFY requests that are related to the previously 
sent REFER request in accordance with RFC 3515 [17] and may indicate the received information to the user. 

NOTE: Additionally, a conference participant can be removed from a conference by other means. 

5.3.1 .7 Consent to list server distribution 

A participant capable of receiving a request to join a conference should support the requirements of a recipient defined 
in RFC 5360 [36]. 

5.3.2 Conference Focus 

5.3.2.1 General 

In addition to the procedures specified in subclause 5.3.2, the conference focus shall support the procedures specified in 
3GPP TS 24.229 [5] appropriate to the functional entity in which the conference focus is implemented. When 
performing 3rd party call control the conference focus shall follow the procedures of subclause 5.7.5 of 
3GPPTS 24.229 [5]. 

5.3.2.2 Generic procedures for all conference related methods at the conference 
focus 

5.3.2.2.1 Conference focus originating case 

The conference focus shall follow the procedures of 3GPP TS 24.229 [5] subclause 5.7.3 when acting as an originating 
UA. 

5.3.2.2.2 Conference focus terminating case 

Upon receipt of a conference related initial request, the conference focus shall follow the procedures of 

3GPP TS 24.229 [5] subclause 5.7.1.2 in relation to the contents of the P-Charging-Function- Addresses header and the 

P-Charging- Vector header. 

When creating the first response for this initial request, the conference focus shall: 

1) include the P-Charging- Vector header including: 

a) the value of the icid parameter as received in the initial request; 

b) the value of the orig-ioi parameter as received in the initial request; and 

c) the term-ioi parameter, indicating the network of the conference focus; and 

2) include the P-Charging-Function- Addresses header as received in the initial request or, if the P-Charging- 
Function- Addresses header was not received in the initial request, indicate the values applicable for the 
conference in the P-Charging-Function- Addresses header. 

When creating responses for an initial INVITE request, the conference focus shall additionally send the 200 (OK) 
response to the initial INVITE request only after the resource reservation has been completed. 
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5.3.2.3 Conference creation 

5.3.2.3.1 Conference creation with a conference factory URI 

Upon receipt of an INVITE request that includes a conference factory URI in the request URI, the conference focus 
shall: 

1) check if the conference factory URI is allocated and reject the request in accordance with RFC 3261 [7] if it is 
not allocated. The following actions in this subclause shall only be performed if the conference factory URI is 
allocated; 

NOTE: The mechanism by which the conference focus gets aware whether a URI is a conference factory URI is 
out of the scope of the present document. One possibility would be that an operator uses a specific user 
part (e.g. conference-factory@homel.net) or host part (e.g. conference-factory.homel.net) for 
identification of conference factory URIs. 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; 

3) allocate a conference URI and if needed a temporary conference URI; and 

4) if "preconditions" were indicated as required in the INVITE request are not satisfied, generate a first provisional 
response to the INVITE request, indicating the temporary conference URI in the Contact header if allocated, else 
the conference URI. 

At the same time, resources will also be requested from the mixer. 

If the conference focus generates any Ixx or 2xx response to the INVITE request, the conference focus shall include the 
"isfocus" feature parameter in accordance with the procedures of RFC 3840 [19]. 

Upon receipt of an indication from the mixer that conference resources have been through-connected, the conference 
focus shall generate a 200 (OK) response to the INVITE request, indicating the "isfocus" feature parameter as a 
parameter to the conference URI in the Contact header. 

5.3.2.3.2 Conference creation with a conference URI 

Upon receipt of an INVITE request that includes a conference URI in the request URI and the conference has not been 
created yet, the conference focus shall: 

1) check if the conference URI is allocated reject the request in accordance with RFC 3261 [7] if it is not allocated. 
The following actions in this subclause shall only be performed if the conference URI is allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; and 

3) if a contact header is included in the response, set the contact header to the conference URI. At the same time, 
resources will also be requested from the mixer. 

If the conference focus generates any Ixx or 2xx response to the INVITE request, the conference focus shall include the 
"isfocus" feature parameter in accordance with the procedures of RFC 3840 [19]. 

Upon receipt of an indication from the conference mixer that conference resources have been through-connected, the 
conference focus shall generate a 200 (OK) response to the INVITE request, indicating the conference URI in the 
Contact header. 

5.3.2.4 User joining a conference 

5.3.2.4.1 User joining a conference by using a conference URI 

Upon receipt of an INVITE request that includes a conference URI in the request URI, the conference focus shall: 
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1) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject 
the request in accordance with RFC 3261 [7]. The following actions in this subclause shall only be performed if 
the conference URI is allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; and 

3) if a contact header is included in the response, set the contact header to the conference URI. 

At the same time, resources will also be requested from the mixer. 

If the conference focus generates any Ixx or 2xx response to the INVITE request, the conference focus shall include the 
"isfocus" feature parameter in accordance with the procedures of RFC 3840 [19]. 

Upon receipt of an indication from the mixer that conference resources have been through-connected, the conference 
focus shall generate a 200 (OK) response to the INVITE request, indicating the conference URI in the Contact header. 

5.3.2.5 Invitation of users to a conference 

5.3.2.5.1 General 

The conference focus can invite users to a conference by sending an INVITE request to the user, as described in 
subclause 5.3.2.5.3. This procedure will be triggered at the conference focus either by a REFER request received from 
authorized users, that request the conference focus to invite other users to the conference, as described in 
subclause 5.3.2.5.2, or by the initial INVITE request that creates the conference when it includes a" recipient-list" 
message body as described in subclause 5.3.1.5.4. 

NOTE: Additionally, invitation of users to a conference can be triggered by other means. 

Additionally, the conference focus can invite users to a conference by sending a REFER request to the user, as 
described in subclause 5.3.2.5.4. How these procedures are triggered is outside the scope of this specification. 

5.3.2.5.2 Request from a user to invite another user to a conference using a REFER 
request 

Upon receipt of an REFER request that includes: 

a) a conference URI in the request URI; and 

b) a Refer-To header including: 

- a vaUd SIP URI or tel URL; and, 

the "method" parameter either set to "INVITE" or omitted; 
NOTE: If the "method" URI parameter is omitted, the conference focus assumes that the method is INVITE, 
the conference focus shall: 

1) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject 
the request in accordance with RFC 3261 [7]. The following actions in this subclause shall only be performed if 
the conference URI is allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; 

3) generate a final response to the REFER request in accordance with RFC 3515 [17]; 

4) invite the user indicated in the Refer-To header by performing the procedures as described in 
subclause 5.3.2.5.4; 

5) if the received REFER request included a Referred-By header, include the Referred-By header in accordance 
with RFC 3892 [20] in the INVITE request that is sent for inviting the user to join the conference; 
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5a) if the received REFER request included a Replaces header, include the Replaces header in accordance with 
RFC 3891 [33] and 3GPP TS 24.229 [5] in the INVITE request that is sent for joining the conference; and 

6) based on the progress of this invitation, send NOTIFY messages in accordance with the procedures of 
RFC 3515 [17] towards the user who sent the REFER request. 

5.3.2.5.3 Request from a user to invite another user to a conference using an INVITE 
request for conference creation 

Upon receipt of an INVITE request for conference creation (see subclause 5.3.2.3) after receiving a valid "recipient-list" 
as defined in RFC 5366 [34], the conference focus shall, in addition to the procedures described in subclause 5.3.2.3, 
perform following actions: 

1) support the procedures of RFC 5360 [36] associated with such a URI list. The conference focus shall act as the 
relay and may act as a store and forward server as defined in RFC 5360 [36]; and 

2) send an INVITE request to each of the SIP URIs contained in the URI list that is embedded in the message body 
of the INVITE request for conference creation, by following the procedures in subclause 5.3.2.5.4. 

The invitation of the users whose SIP URIs are included in the URI list should be initiated by the conference focus in 
parallel, since the objective of using the URI-list method of inviting users to a conference is usually a fast conference 
set-up. However, in case the conference focus is not able to keep track of multiple parallel invitations associated to a 
single conference the conference focus may issue the invitations serially. 

Sending of the multiple invitations should be initiated by the MRFC/AS as soon as a conference URI for the conference 
has been created, and should run in parallel to the procedure described in subclause 5.3.2.3 in order to speed up 
conference establishment. If establishment of a session to any of the invitees fails, the further actions depends on local 
policy whether the conference will continue with the accepted participants or release the whole conference. 

If the conference focus is included in the signalling path between the conference creator and the invited user as a B2B 
UA, and 

if the URIs in the URI list contain a Session-ID header field, the focus shall verify if the Session ID information 
matches to a partial dialog between the focus and the conference creator; else 

if the URIs in the URI list contain Call-ID header field. From header field and To header field, the focus shall 
verify if this dialog ID information matches to a partial dialog between the focus and the conference creator. 

In the case of a match the focus may use this information to send re-INVITE request in the partial dialogs between the 
focus and the invited users in order to connect the media of the invited users to the MRFP. 

In the case of no match the focus shall discard Call-ID header field. From header field. To header field and Session-ID 
header field form the URIs in the URI list, if those header fields are included. 

5.3.2.5.4 Inviting a user to a conference by sending an INVITE request 

When generating an INVITE request in order to invite a user to a specific conference, the conference focus shall: 

1) set the request URI of the INVITE request to the address of the user who is invited to the conference; 

2) set the P-Asserted-Identity header of the INVITE request to the conference URI of the conference that the user 
shall be invited to; 

3) set the Contact header of the INVITE request to the conference URI of the conference that the user shall be 
invited to, including the "isfocus" feature parameter; 

4) if the INVITE request is generated due to a received REFER request from another conference participant and 
that received REFER request included a Referred-By header, include the Referred-By header in accordance with 
RFC 3892 [20] in the INVITE request; 

4a) if the INVITE request is generated due to a received REFER request from another conference participant and the 
received REFER request included a Replaces header, include the Replaces header in accordance with 
RFC 3891 [33] and 3GPP TS 24.229 [5] in the INVITE request; 

5) send the INVITE request towards the user who is invited to the conference. 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 21 ETSI TS 1 24 1 47 VI 0.2.0 (201 2-01 ) 

NOTE 1 : The conference focus will request the resources required for the new user from the conference mixer. 
NOTE 2: Requests are generated in accordance with 3GPP TS 24.229 [5]. 
Afterwards the conference focus shall proceed the session establishment as described in 3GPP TS 24.229 [5]. 

5.3.2.5.5 Inviting a user to a conference by sending a REFER request 

When generating a REFER request in order to invite a user to a specific conference, the conference focus shall: 

1) set the request URJ of the REFER request to the address of the user who is invited to the conference; 

2) set the P-Asserted-Identity header of the REFER request to the conference URI of the conference that the user 
shall be invited to; 

3) set the Refer-To header of the REFER request to the conference URI of the conference that the other user shall 
be invited to, and either including the "method" URI parameter set to "INVITE" or omitting the "method" URI 
parameter; and 

NOTE 1: Other headers of the REFER request will be set in accordance with 3GPP TS 24.229 [5]. 

4) send the REFER request towards the user who is invited to the conference. 

NOTE 2: Requests are generated in accordance with 3GPP TS 24.229 [5]. 

Afterwards the conference focus shall treat incoming NOTIFY requests that are related to the previously sent REFER 
request in accordance with RFC 3515 [17]. 

5.3.2.6 Leaving a conference 

5.3.2.6.1 Conference participant leaving a conference 

Upon receipt of a BYE message from a conference participant, the conference focus shall: 

1) respond to the BYE request as described in 3GPP TS 24.229 [5] and RFC 3261 [7]; and 

2) release the resources, related to the conference participant from the conference mixer. 

5.3.2.6.2 Removing a conference participant from a conference 

5.3.2.6.2.1 General 

The conference focus can remove a conference participant from a conference by terminating the dialog with the 
conference participant. This is done by sending a BYE request to the participant, as described in subclause 5.3.2.6.2.3. 
The removal of a conference participant by the conference focus will be triggered: 

1) by a REFER request received from authorized users, that request the conference focus to remove the conference 
participant from the conference, as described in subclause 5.3.2.6.2.2; or 

2) by local administration procedures. 

NOTE: Additionally, a conference participant may be removed from a conference by other means. 

5.3.2.6.2.2 Request from a conference participant to remove anotiner conference participant from 
a conference 

Upon receipt of a REFER request that includes: 

a) a conference URI in the request URI; and, 

b) a Refer-To header including: 
1) a valid SIP URI; and 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 22 ETSI TS 1 24 1 47 V1 0.2.0 (201 2-01 ) 

2) the "method" parameter set to "BYE". 
The conference focus shall: 

1) check if the conference URI is allocated. If the conference URI is not allocated, the conference focus shall reject 
the request in accordance with RFC 3261 [7]. The following actions in this subclause shall only be performed if 
the conference URI is allocated; 

1 A) if the SIP URI contains a user parameter that equals "phone" and if the SIP URI of the Refer-To header can be 
converted to a global tel URI as described in RFC 3261 [7], convert the SIP URI to the equivalent global tel 
URI. Verify that the tel URI belongs to user who is currently a participant of the referenced conference. If this 
verification fails, then reject the request in accordance with RFC 3261 [7] and RFC 3515 [17]; 

2) check if the SIP URI of the Refer-To header is identical to the conference URI or belongs to a user who is 
currently a participant of the referenced conference. If this verification fails, then reject the request in accordance 
with RFC 3261 [7] and RFC 3515 [17]; 

3) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions in this subclause shall only be 
performed if the request can be authorized; 

4) generate a final response to the REFER request in accordance with RFC 3515 [17]; 

5) if a single conference participant is indicated in the Refer-To header, remove this conference participant from the 
conference according to subclause 5.3.2.6.2.3. If the Refer-To header includes the conference URI, remove all 
conference participants from the conference by performing the procedures described in subclause 5.3.2.6.2.3 for 
each conference participant individually; and 

6) based on the progress of this removal, send NOTIFY messages in accordance with the procedures of 
RFC 3515 [17] towards the conference participant who sent the REFER request. 

5.3.2.6.2.3 Conference focus removes conference participant from a conference 

When removing a conference participant from a conference, the conference focus shall: 

1) generate a BYE request on the dialog that was established when the conference participant joined or created the 
conference, in accordance to the procedures described in 3GPP TS 24.229 [5] and RFC 3261 [7]; 

2) release the resources, related to the conference participant from the conference mixer. 

5.3.2.7 Conference termination 

A conference shall be terminated by the conference focus: 

1) when the conference has been created by means of the procedure described in subclause 5.3.2.5.3 and session 

establishment to one or more of the invitees has failed; or 

2) when the conference policy dictates it; or 

3) when no dedicated rules for conference termination exist in the conference policy; and: 

either the conference was created with a conference factory URI and the conference creator has left the 
conference; or 

the last conference participant has left or has been removed from the conference. 

NOTE: How the conference policy can be created or changed is out of the scope of this specification. 

To terminate an existing conference, the conference focus shall: 

1) remove all present conference participants from the conference by performing the procedures as described in 
subclause 5.3.2.6.2.3 for each participant individually; and 

2) deallocate the conference URI. 
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5.3.3 Conference Notification Service 

5.3.3.1 General 

In addition to the procedures specified in subclause 5.3.3, the conference notification service shall support the 
procedures specified in 3GPP TS 24.229 [5] appropriate to the functional entity in which the conference notification 
service is implemented. 

5.3.3.2 Subscription to conference event package 

Upon receipt of a SUBSCRIBE request that includes a conference URI in the request URI and the "conference" tag in 
the Event header, the conference notification service shall: 

1) check if the conference URI is allocated and reject the request in accordance with RFC 3261 [7] if it is not 
allocated. The following actions in this subclause shall only be performed if the conference URI is allocated; 

2) verify the identity of the user as described in subclause 5.7. 1 .4 of 3GPP TS 24.229 [5] and authorize the request 
as described in subclause 5.7.1.5 of 3GPP TS 24.229 [5]. The following actions shall only be performed if the 
request can be authorized; and 

3) establish the subscription to the conference state event information as described in RFC 3265 [10] and 
RFC 4575 [11]. 

5.3.3.3 Leaving a conference 

When generating a NOTIFY request with conference state event information that is destined to a subscriber that has 
either left the conference or was removed from it, the conference notification service shall, include in the NOTIFY 
request a Subscription-State header with the value "terminated" in accordance with RFC 3265 [10]. 

5.3.3.4 Conference termination 

The conference notification service shall terminate all subscriptions to the conference event package in accordance with 
RFC 4575 [11] when the conference is terminated, as described in subclause 5.3.2.7. 

6 Protocol using SDP for conferencing 

6.1 Introduction 

Void 

6.2 Functional entities 

6.2.1 User Equipment (UE) 

For the purpose of SIP based conferences, the UE shall implement the role of a conference participant as described in 
subclause 6.3.1. 

6.2.2 Media Resource Function Controller (MRFC) 

For the purpose of SIP based conferences, the MRFC shall support the procedures for media control of ad-hoc 
conferencing described in subclause 10.3 of 3GPP TS 24.229 [5]. 
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6.2.3 Conferencing Application Server (Conferencing AS) 

For the purpose of SIP-based conferences, the conferencing AS shall act as a conference focus, as described in 
subclause 6.3.2. The conferencing AS may implement the role of a conference participant as described in 
subclause 6.3.1. 

The conferencing AS shall use the procedures for media control in subclause 10.2 of 3GPP TS 24.229 [5] to implement 
SIP based conferences. 

6.2.4 Media Gateway Control Function (MGCF) 

The MGCF implements the role of Conference participant (see subclause 6.3.1). 

6.3 Role 

6.3.1 Conference Participant 

The conference participant shall support the procedures specified in 3GPP TS 24.229 [5] appropriate to the functional 
entity in which the conference participant is implemented. 

If the conference participant uses BFCP as specified in clause 8, then the conference participant shall support the 
procedures specified in RFC 4583 [35]. 

6.3.2 Conference Focus 

In addition to the procedures specified in subclause 6.3.2, the conference focus shall support the procedures specified in 
3GPP TS 24.229 [5] appropriate to the functional entity in which the conference focus is implemented. 

If the conference focus uses BFCP as specified in clause 8, then the conference focus shall support the procedures 
specified in RFC 4583 [35]. 

NOTE: RFC 4582 [28] recommends the use of Transport Layer Security (TLS) for the secure exchange of BFCP. 
Whether this is followed, and the mechanism for the exchange of the certificates in association with SDP 
are outside the scope of this version of this document. 

When the conference focus receives any SIP request or response containing SDP, the conference focus shall examine 
the media parameters in the received SDP. 

Provided that the INVITE request received by the conference focus contains an SDP offer including one or more "m=" 
media descriptions, the SDP answer shall: 

reflect the media capabilities and policies as available for the conference; and 

contain a request confirmation for the result of the resource reservation at the originating end point for every 
"m=" media line if preconditions were required by the originator. 



During session establishment procedure for a conference, SIP messages shall only contain SDP payload if that is 
intended to modify the session description. 

For "video" and "audio" media types that utilize the RTP/RTCP, the conference focus shall specify the proposed 
bandwidth for each media stream utilizing the "b=" media descriptor in the SDP. For other media streams the "b=" 
media descriptor may be included. The value or absence of the "b=" parameter will affect the assigned QoS which is 
defined in 3GPP TS 29.208 [15]. 

The conference focus shall include the DTMF media format at the end of the "m=" media descriptor in the SDP for 
audio media flows that support both audio codec and DTMF payloads in RTP packets as described in RFC 2833 [16]. 

Upon receipt of a SDP answer or sending a SDP answer that changes the resource requirements for the conference, the 
conference focus shall provide the corresponding changes of conference resources. 

Upon receipt of a SDP offer during conference creation, that confirms that the conference participant has reserved the 
required resources, the conference focus shall through-connect the conference resources. 
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Void. 



8 Protocol for floor control for conferencing 

8.1 Introduction 

Support of floor control is optional for participants and MRFP. 

8.2 Functional entities 

8.2.1 User Equipment (UE) 

A UE may support the floor participant (see subclause 8.3.1) or floor chair role (see subclause 8.3.2). A floor chair may, 
but need not, be a floor participant. 

8.2.2 Media Resource Function Processor (MRFP) 

An MRFP may support the floor control server role (see subclause 8.3.3), the floor chair role (see subclause 8.3.2), or 
the floor participant role (see subclause 8.3. 1). 

8.3 Role 



8.3.1 Floor participant 



The floor participant shall support general client operations and floor participant operations as described in 

RFC 4582 [28]. 

BFCP messages shall be sent on any IP-CAN transport used for media in accordance with subclause 9.2.2 of 
3GPPTS.24.229[5]. 

8.3.2 Floor chair 

The floor chair shall support client operations and floor chair operations as described in RFC 4582 [28]. 

BFCP messages shall be sent on any IP-CAN transport used for media in accordance with subclause 9.2.2 of 
3GPPTS.24.229[5]. 

8.3.3 Floor control server 

The floor control server shall support floor control server operations as described in RFC 4582 [28]. 

NOTE: It is out of scope of this version of the document how the floor control server discovers the floor control 

policy of the conference, and how the floor control server manipulates the media policy of the conference 
due to changes in the status of any floor. 
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Annex A (informative): 

Example signalling flows of conferencing operation 

A.1 Scope of signalling flows 

This annex gives examples of signalling flows for conferencing within the IP Multimedia CN Subsystem (IMS) based 
on the Session Initiation Protocol (SIP), SIP Events and the Session Description Protocol (SDP). 

These signalling flows provide detailed signalling flows, which expand on the overview information flows provided in 
3GPPTS 23.228 [6]. 

These signalling flows are simplified in that they do not show the AS to MRFC interactions nor the AS and MRFC 
functional split. 



A.2 Introduction 
A.2.1 General 

This annex breaks down the signalling flows for establishing sessions into a number of individual procedures, following 
the same principles as 3GPP TS 23.228 [3] subclause 5.4.9. 

For the purposes of the present document, a further breakdown has been necessary, and therefore a number of signalling 
flows have been given an (a) or (b) suffix, so that the signalling flows for establishing sessions where configuration 
independence is applied may be distinguished from those where it is not, e.g.: 

(MO#la) Mobile origination, roaming, without I-CSCF providing configuration independence. 

(MO#lb) Mobile origination, roaming, with I-CSCF in home network providing configuration independence. 

A.2. 2 Key required to interpret signalling flows 

The key to interpret signalling flows specified in 3GPP TS 24.228 [4] subclause 4. 1 applies with the additions specified 
below: 

#### represents the contents in the headers are not shown and does not impact the implementation of the flows. 

As in 3GPP TS 24.228 [4], in order to differentiate between SIP methods and other protocol messages, the message 
name is preceded with the associated protocol for all non-SIP messages. 

Each flow table contains descriptions for headers where the content of the header is new to that flow, as is already 
performed in 3GPP TS 24.228 [4]. 

However, 3GPP TS 24.228 [4] includes extensive descriptions for the contents of various headers following each of the 
tables representing the contents of the flows. Where the operation of the header is identical to that shown in 
3GPP TS 24.228 [4], then such text is not reproduced in the present document. 

Additional text may also be found on the contents of headers within 3GPP TS 24.228 [4] in addition to the material 
shown in the present document. 

A.2. 3 Overview of signalling flows related to PSI routeing 

The flows in this annex reflect examples for some of the PSI specific routing scenarios. This subclause gives a list of 
the PSI scenarios and indicates which flows specifically cover them: 

1) User originating a dialog towards a PSI. 
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a) PSI is hosted by the originating users home network. 

i) S-CSCF of originating user can directly route towards the AS hosting the PSI. 

This case is shown in subclauses A. 3. 2.1 and A.4.4.1. 

ii) PSI is statically pre-configured, i.e. S-CSCF of the originating user routes towards the S-CSCF assigned 
to the PSI, which afterwards routes towards the AS hosting the PSI. 

This case is not covered by the present document. 

b) PSI is hosted by a network different from the originating users home network. 

i) PSI can be resolved directly by the S-CSCF located in the originating users home network. 

This case is shown in subclauses A.4.2.1.2 and A.5.2.1. 

ii) S-CSCF in originating users home network can only resolve an I-CSCF of the network that is hosting the 
PSI. 

I-CSCF can directly route towards the AS hosting the PSI. 

This case is shown in subclauses A. 3. 2. 2 and A.4.2.1.1. 

PSI is statically pre-configured, i.e. I-CSCF routes first to S-CSCF in the network that hosts the PSI, 
the S-CSCF afterwards routes towards the AS hosting the PSI. 

This case is not covered by the present document. 

2) Dialog originates from a PSI. 

a) AS routes directly to the I-CSCF of the terminating users home network. 
This case is shown in subclause A.4.3.1.3. 

b) AS routes first to a S-CSCF in the network hosting the PSI, which then routes to the I-CSCF of the 
terminating users home network. 

This case is shown in subclause A.4.3.1.4. 

3) Dialog originating from a PSI and terminating at a different PSI. 
This case is not covered by the present document. 
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A.3 Flows demonstrating the creation of a conference 
A.3.1 Introduction 

Clause A.3 covers the flows that show how a user can create conferences at a MRFC/AS. 

A.3. 2 User automatically creating a conference with a conference 
factory URI 

A.3. 2.1 MRFC/AS is located in user's inome network 



Visited Networl< 



Home Networl< 



UE#1 
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Figure A.3.2.1-1 : User automatically creating a conference with a conference factory URI - IVIRFC/AS 

is located in user's home network 

Figure A.3.2.1-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a 
MRFC/AS of the users home network. 

The details of the flows are as follows: 

1. INVITE request (UE to P-CSCF) - see example in table A.3.2.1-1 

A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was 
obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as 
http). 

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a 
SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for 
each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), 
there may be multiple codec choices offered. 

For this example, it is assumed that UE#1 is willing to establish a multimedia session comprising a video 
stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The 
audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF. 

The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require' header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 
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Table A.3.2.1-1 : INVITE request (UE to P-CSCF) 



INVITE sip : conf erence-f actorylOmrf cl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erence-f actorylOmrf cl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept: application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: contains the conference factory URL 

2. 100 (Trying) response (P-CSCF to UE) - see example in table A.3.2.1-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response. 

Table A.3.2.1-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



3. INVITE request (P-CSCF to S-CSCF) - see example in table A.3.2.1-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 
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Table A.3.2.1-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip : conference- factorylOmrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : G9 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip ipcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Inf o : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response. 

Table A.3.2.1-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP pcsc 
[5555: :aaa:bbb:ccc 


f 1 .visitedl 
:ddd] :1357; 


.net 
comp= 


branch= 
= sigcomp 


z9hG4bK240f34.1, SIP/2 
;branch=z9hG4bKnashds7 


0/UDP 


From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 
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The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF to MRFC/AS) - see example in table A.3.2.1-6 

The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request 
URL The S-CSCF does not re-write the Request URL 

Table A.3.2.1-6: INVITE request (S-CSCF to MRFC/AS) 



INVITE sip : conference- factorylOmrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net ; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Access-Network-Info : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c8 8 :d77 : eSS] ; ccf = [5555 : : a55 :b44 : c33 :d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. 100 (Trying) response (MRFC/AS to S-CSCF) - see example in table A.3.2.1-7 (related to table A.3.2.1-6) 

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response. 
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Table A.3.2.1-7: 100 (Trying) response (MRFC/AS to S-CSCF) 



SIP/2.0 100 Trying 














Via: SIP/2 


.0/UDP scscfl.homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . 


visitedl 


net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: : 


aaa :bbb : ccc :ddd] :1357;comp= 


=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Le 


ngth : 















8. Allocate conference URI 

The MRFC/AS allocates a conference URI, based on local information and information gained from the 
conference-factory URI, as well as information gained from other elements of the SIP signalling. 

9. H.248 interaction to create connection 

The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to 
determine media capabilities of the MRFP. 

10. 183 (Session Progress) response (MRFC/AS to S-CSCF) - see example in table A.3.2.1-13 (related to 
table A.3.2.1-6) 

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It 
determines the intersection with those appearing in the SDP in the INVITE request. 

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session 
Progress) provisional response (to 6). 
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Table A.3.2.1-10: 183 (Session Progress) response (MRFC/AS to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity : "Conference Server" <sip imrfcl .homel .net> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term- ioi=homel . net 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e6 6]; ccf=[5555::a5 5:b44:c33:d22]; 

ecf= [5555: :lff :2ee:3dd:4cc] ; ecf= [5555 : : 6aa : 7bb : 8cc : 9dd] 
Privacy: none 
From: 

To: <sip : conference-factorylOmrfcl .homel .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 

Contact : <sip : lmaa234269@mrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



Contact: Contains the IP address or FQDN of the MRFC/AS and a temporary identifier of 

the conference being created in the user part. The URI for the allocated 
conference is not indicated yet. The "isfocus" feature parameter is included, as 
this temporary contact is still a conference URI. 

P-Charging- Vector: The MRFC/AS inserts this header and populates the icid parameters with a 

unique value and populates the term-ioi parameter with the identifier of its own 
network. 

P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function- Addresses header field to be 

passed to the S-CSCF. 

1 1. 183 (Session Progress) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-11 

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 
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Table A.3.2.1-11 : 183 (Session Progress) response (S-CSCF to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e6 6]; ccf=[5555::a5 5:b44:c33:d22] 

ecf= [5 555: :lff :2ee:3dd:4cc] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy. 

13 183 (Session Progress) response (P-CSCF to UE) - see example in table A.3.2.1-13 

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint. 
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Table A.3.2.1-13: 183 (Session Progress) response (P-CSCF to UE) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip ipcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



14. Resource reservation 

The originating UE sets up the bearer in accordance with the media description received SDP. 

15. PRACK request (UE to P-CSCF) - see example in table A.3.2.1-15 

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 



Table A.3.2.1-15: PRACK request (UE to P-CSCF) 



PRACK sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route: <sip :pcscfl .visitedl .net : 7531; lr;comp=sigcomp>, <sip : scscfl .homel .net ; lr> From: 

<sip : userl_publicl@homel . net> ; tag=171828 
To : <sip : conf erence-f actorylOmrf cl .homel .net>; tag=31415 9 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 128 PRACK 

Require: precondition, sec-agree 
Proxy-Require: sec-agree 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
RAck: 9021 127 INVITE 
Content-Length: 
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16. PRACK request (P-CSCF to S-CSCF) - see example in table A.3.2.1-16 

The P-CSCF forwards the PRACK request to the S-CSCF. 

Table A.3.2.1-16: PRACK request (P-CSCF to S-CSCF) 



PRACK sip: lmaa234269@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Inf o : 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
RAck: 
Content-Length : 



17. PRACK request (S-CSCF to MRFC/AS) - see example in table A.3.2.1-17 

The S-CSCF forwards the PRACK request to the MRFC/AS. 

Table A.3.2.1-17: PRACK request (S-CSCF to MRFC/AS) 



PRACK sip: lmaa234269@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1. homel. net ;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 .visitedl .net ;branch= 


=z9hG4bK240f34.: 


, SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc:ddd] 
Max- Forwards : 68 


1357;comp= 


=sigcomp. 


branch= 


z9hG4bKnashds7 


P-Access-Network-Info : 














From: 














To: 














Call-ID: 














Cseq: 
Require : 

RAck: 














Content-Length: 















18. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.3.2.1-18 (related to table A.3.2.1-17) 

The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response. 

Table A.3.2.1-18: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 














Via: SIP/2. 0/UDP scscf 1. homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 .visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc:ddd] :1357;comp= 


=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 















19. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to 
reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between 
the UE#1 and the MRFC. 
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20. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-20 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.2.1-20: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



21. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.1-21 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.2.1-21 : 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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22. UPDATE request (UE to P-CSCF) - see example in table A.3.2.1-22 

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the 
signalHng path estabUshed by the INVITE request. 

Table A.3.2.1-22: UPDATE request (UE to P-CSCF) 



UPDATE sip: lmaa234269@mrfcl .homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erence-f actorylomrf cl .homel .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S17 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telphone-event 
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23. UPDATE request (P-CSCF to S-CSCF) - see example in table A.3.2.1-23 

The P-CSCF forwards the UPDATE request to the S-CSCF. 

Table A.3.2.1-23: UPDATE request (P-CSCF to S-CSCF) 



UPDATE sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ; 

ggsn= [5555 : :4b4 :3c3 :2d2 : lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559 ; flow-id=3 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 41 ETSI TS 1 24 1 47 VI 0.2.0 (201 2-01 ) 

24. UPDATE request (S-CSCF to MRFC/AS) - see example in table A.3.2.1-24 

The S-CSCF forwards the UPDATE request to the MRFC/AS. 

Table A.3.2.1-24: UPDATE request (S-CSCF to MRFC/AS) 



UPDATE sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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25. 200 (OK) response (MRFC/ASto S-CSCF) - see example in table A.3.2.1-25 (related to table A.3.2.1-24) 

The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response. 

Table A.3.2.1-25: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

26. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in 
MRFP. 
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27. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-27 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.2.1-27: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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28. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.1-28 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.2.1-28: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



29. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.3.2.1-29 (related to table A.3.2.1-6) 

After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response 
to the INVITE request (6) to the S-CSCF. 

Table A.3.2.1-29: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 
Allow-Events : conference, pending-additions 
Content-Length: 



Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages. 
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30. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.1-30 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.3.2.1-30: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow- Events : 
Content-Length : 



3 1 . Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12). 

32. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.1-32 

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the 
media flow(s) for this session. 

Table A.3.2.1-32: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow- Events : 

Content-Length : 



33. ACK request (UE to P-CSCF) - see example in table A.3.2.1-33 

The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK 
request sent to the P-CSCF. 

Table A.3.2.1-33: ACK request (UE to P-CSCF) 



ACK sip : conferencelOmrfcl .homel 


net:2342 


SIP/2 


.0 










Via: SIP/2. 0/UDP [5555: :aaa 


bbb 


ccc :ddd] 


:1357; 


comp=sigcomp; 


oranch= 


z9hG4bKnas 


tids7 


Max- Forwards : 7 


















Route: <sip :pcscfl .visitedl 


net 


7531; Ir; 


comp=sigcomp>, <sip 


: scscf 1 


.homel 


net 


; lr>From: 


<sip:userl publicl@homel 


net = 


; tag=171828 












To : <sip : conference -factorylOmrfcl .homel 


.net>; 


tag=314159 










Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 














Cseq: 127 ACK 


















Content-Length: 
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34. ACK request (P-CSCF to S-CSCF) - see example in table A.3.2.1-34 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.3.2.1-34: ACK request (P-CSCF to S-CSCF) 



ACK sip : conferencelOmrfcl .homel .net : 2342 SIP/2.0 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 


Max- Forwards : 69 


Route : <sip : scscf 1 .homel .net; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length: 



35. ACK request (S-CSCF to MRFC/AS) - see example in table A.3.2.1-35 

The S-CSCF forwards the ACK request to the MRFC/AS. 

Table A.3.2.1-35: ACK request (S-CSCF to MRFC/AS) 



ACK sip : conference 


lOmrfcl . 


homel 


.net:2342 SIP/2 









Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1. visitedl 


.net ;branch=z 


3hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc :ddd] 


:1357 


-comp=sigcomp;branch= 


z9hG4bKnashds7 


Max- Forwards : 68 














From: 














To: 














Call-ID: 














Cseq: 














Content-Length: 















A.3.2.2 MRFC/AS is not locatecJ in user's inome network 

Figure A. 3.2. 2-1 shows an user creating a conference by using a conference-factory URI. The conference is created at a 
MRFC/AS located in a different network than user's S-CSCF. 
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Visited Network 



Home Network 



Conference AS home network 



— 1.INVITE- 
-2. 100 Trying- 



— 3. INVITE — 
-4. lOOTrying- 



5. Evaluation of initial 
Filter Criteria 



_15. 183 Session_ 
Progress 



16. Authorize QoS resources 



_17. 183Session_ 
Progress 



18. Resource 
Reservation 



—25. 200 OK— 
-26. UPDATE- 



—20. PRACK— 
—24. 200 OK— 

-27. UPDATE- 



36. Approval of OoS Commit 



-37. 200 OK- 
— 38. ACK — 



— 6. INVITE 

-7. lOOTrying- 



. PSI location 
query 



_14. 183Session_ 
Progress 



9. INVITE— 

-10. 100 Trying- 



1 1 . Allocate 
Conference URI 



12. H.248 interaction to create 

conference connection resources for 

UE#1 



_13. 183Session_ 
Progress 



-21 . PRACK- 
-22. 200 OK- 



23. H.248 interaction to modify 

conference connection resources for 

UE#1 



-28. UPDATE- 

I 
—29. 200 OK— 



30. H.248 interaction to connect 

through conference connection 

resources for UE#1 



Figure A.3.2.2-1 : User automatically creating a conference with a conference factory URI 
MRFC/AS is not located in user's home network 

The details of the flows are as follows: 



1. INVITE request (UE to P-CSCF) - see example in table A.3.2.2-1 



A UE wants to create a conference to a MRFC/AS in other network. For this purpose the UE is aware of a 
conference-factory URI that was obtained by means outside the present document (e.g. due to pre- 
configuration or via other protocols, such as http) 

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a 
SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for 
each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), 
there may be multiple codec choices offered. 

For this example, it is assumed that the UE is willing to establish a multimedia session comprising a video 
stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The 
audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF. 
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The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require" header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 



Table A.3.2.2-1 : INVITE request (UE to P-CSCF) 



INVITE sip:conference-factory@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route: <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erence-f actory@home2 .net> 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact: <sip: userl_publicl@homel.net; gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 

; comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 :MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



Request-URI: contains the conference factory URL 
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2. 100 (Trying) response (P-CSCF to UE) - see example in table A.3.2.2-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response. 

Table A.3.2.2-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 (Trying) response 




Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





3. INVITE request (P-CSCF to S-CSCF) - see example in table A.3.2,2-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 

Table A.3.2.2-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip : conference- factory@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.3.2.2-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response. 

Table A.3.2.2-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP pcsc 


response 
fl.visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] :1357; 


comp= 


=sigcomp 


;branch= 


z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF to I-CSCF) - see example in table A.3.2.2-6 

S-CSCF determines the network where the INVITE request should be forwarded. The S-CSCF resolves the 
I-CSCF as the next hop for this request. 

Table A.3.2.2-6: INVITE request (S-CSCF to I-CSCF) 



INVITE sip : conference- factory@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net ; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



£75/ 



3GPP TS 24.147 version 10.2.0 Release 10 



51 



ETSI TS 124 147 VI 0.2.0 (2012-01) 



7. 100 (Trying) response (I-CSCF to S-CSCF) - see example in table A.3.2.2-7 

The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response. 

Table A.3.2.2-7: 100 (Trying) response (I-CSCF to S-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP scsc 


response 
f 1 .homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . visitedl .net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc 


:ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 












To: 












Call-ID: 












CSeq: 

Content-Length: 













8. Public service identity (PSI) location query 

The I-CSCF resolves the conference-factory URL In this example the I-CSCF queries HSS to resolve the 
MRFC/AS PSI to be contacted. The HSS responds with the address of the MRFC/AS. 

For detailed message flows see 3GPP TS 29.228 [12] . 

Table A.3.2.2-8a provides the parameters in the SIP INVITE request, which are sent to the HSS. 

Table A.3.2.2-8a Cx: User location query procedure (I-CSCF to HSS) 



Message source and 
destination 


Cx: Information element 
name 


Information source in 
SIP INVITE 


Description 


I-CSCF to HSS 


Public Service Identity 
(PSI) 


Request-URI: 


This information element indicates 
the public user identity 



Table A.3.2.2-8b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and sent 
to MRFC/AS. 

Table A.3.2.2-8b Cx: User location query procedure (HSS to I-CSCF) 



IVIessage source and 
destination 


Cx: Information element 
name 


Mapping to SIP header in 
SIP INVITE 


Description 


HSS to I-CSCF 


MRFC/AS address 


IP packet destination 
address 


This information element indicates 
the IVIRFC/AS address which 
serves the PSI. 
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9. INVITE request (I-CSCF to MRFC/AS) - see example in table A.3.2.2-9 

I-CSCF forwards the INVITE request to the MRFC/AS. The I-CSCF does not add itself to the Record-Route 
header since it does not need to stay on the signalling path for subsequent requests. 

Table A.3.2.2-9: INVITE request (I-CSCF to MRFC/AS) 



INVITE sip : conference- factory@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscfl.home2 .net;branch=z9hG4bK32f432 .1, SIP/2. 0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. 100 (Trying) response (MRFC/AS to I-CSCF) - see example in table A.3.2.2-10 (related to table A.3.2.2-9) 

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) response provisional response. 

Table A.3.2.2-10: 100 (Trying) response (MRFC/AS to I-CSCF) 



SIP/2.0 100 (Trying) response 
Via: SIP/2. 0/UDP icscfl.home2 


net ;branch=z9hG4bK32f 432.1, SIP/2 


0/UDP 


scscf 1 
pcscf 1 


homel. net ;branch=z9hG4bK332b23.1, 
visitedl. net ;branch=z9hG4bK240f 34 


SIP/2. 0/UDP 

1, SIP/2. 0/UDP 




[5555: 


aaa:bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 


From: 












To: 












Call-ID: 












CSeq: 

Content -Length: 
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1 1 . Allocate conference URI 

MRFC/AS allocates a conference URI, based on local information and information gained from the 
conference-factory URI, as well as information gained from other elements of the SIP signalling. 

12. H.248 interaction to create connection 

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP and to determine media 
capabiHties of MRFP. 

13. 183 (Session Progress) response (MRFC/AS to I-CSCF) - see example in table A.3.2.2-13 (related to table 
A.3.2.2-9) 

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It 
determines the intersection with those appearing in the SDP in the INVITE request. 

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session 
Progress) provisional response (to 8). 

Table A.3.2.2-13: 183 (Session Progress) response (MRFC/AS to I-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 1 . home2 . net ;branch=z9hG4bK32f 432 . 1 , SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 5 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity : "Conference Server" <sip :mrf cl .home2 .net> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
P- Charging- Function-Addresses : ccf= [5555 : :b99 : c88 :d77 : e6 6] ; ccf = [5555 : : a5 5 : b44 : c3 3 : d22] ; 

ecf= [5555: : Iff :2ee:3dd:4cc] ; ecf = [5555 : : 6aa : 7bb : Bcc : 9dd] 
Privacy: none 
From: 

To: <sip : conf erence-f actoryl@home2 .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 

Contact : <sip : conf erencelOmrf cl . home2 . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 
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Contact: Contains the conference URI for the conference allocated at the MRFC/AS and 

the "isfocus" feature parameter. 

P-Charging- Vector: The MRFC/AS inserts the originating lOI parameter received and populates the 

terminating lOI parameter with its own network. 

P-Charging-Function-Addresses: The MRFC/AS inserts the P-Charging-Function- Addresses header field to be 

passed to the I-CSCF. 

14. 183 (Session Progress) response (I-CSCF to S-CSCF) - see example in table A.3.2.2-14 

The I-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 

Table A.3.2.2-14: 183 (Session Progress) response (I-CSCF to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 135 7 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 
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15. 183 (Session Progress) response (S-CSCF to P-CSCF) - see example in table A,3.2,2-15 

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 

Table A.3.2.2-15: 183 (Session Progress) response (S-CSCF to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : :aaa:bbb: ccc :ddd] : 13 57 ; comp=sigcomp ; branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023 551024" ; 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 



a= 
a= 
a= 
a= 
a= 



16. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after 200 (OK) response of INVITE request (34) based on operator local policy. 
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17. 183 (Session Progress) response (P-CSCF to UE) - see example in table A.3.2.2-17 

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint. 

Table A.3.2.2-17: 183 (Session Progress) response (P-CSCF to UE) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:CCC:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



18. Resource reservation 

The originating UE sets up the bearer in accordance with the media description received SDP. 

19. PRACK request (UE to P-CSCF) - see example in table A.3.2.2-19 

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 
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Table A.3.2.2-19: PRACK request (UE to P-CSCF) 



PRACK sipiconferencelOmrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conference- factoryl@home2 .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 128 PRACK 

Require: precondition, sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
RAck: 9021 127 INVITE 
Content-Length: 



20. PRACK request (P-CSCF to S-CSCF) - see example in table A.3.2.2-20 

The P-CSCF forwards the PRACK request to the S-CSCF. 

Table A.3.2.2-20: PRACK request (P-CSCF to S-CSCF) 



PRACK sip:conferencel@mrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Inf o : 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
RAck: 
Content-Length : 



21. PRACK request (S-CSCF to MRFC/AS) - see example in table A.3.2.2-21 

The S-CSCF resolves the Request-URl and forwards the PRACK request directly to the MRFC/AS. 

Table A.3.2.2-21 : PRACK request (S-CSCF to MRFC/AS) 



PRACK sip:conferencel@mrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
RAck: 
Content-Length : 
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22. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.3.2.2-22 (related to table A.3.2.2-21) 

The MRFC/AS acknowledges the PRACK request (20) with a 200 (OK) response. 

Table A.3.2.2-22: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 












Via: SIP/2. 0/UDP scscfl.homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc:ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 












To: 












Call-ID: 












CSeq: 












Content-Length: 













23. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to modify the connection established in step #1 1 and instructs MRFP to 
reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation 
between the UE#1 and the MRFC. 

24. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.2-24 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.2.2-24: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34.1, SIP/2 


0/UDP 


[5555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





25. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.2-25 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.2.2-25: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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26. UPDATE request (UE to P-CSCF) - see example in table A.3.2.2-26 

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the 
signalHng path estabUshed by the INVITE request. 

Table A.3.2.2-26: UPDATE request (UE to P-CSCF) 



UPDATE sip:conferencel@mrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conference- factoryl@home2 .net>; tag=31415 9 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S17 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telphone-event 
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27. UPDATE request (P-CSCF to S-CSCF) - see example in table A.3.2.2-27 
The P-CSCF forwards the UPDATE request to the S-CSCF. 

Table A.3.2.2-27: UPDATE request (P-CSCF to S-CSCF) 



UPDATE sipiconferecelOmrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ; 

ggsn= [5555 : :4b4 :3c3 :2d2 : lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559 ; flow-id=3 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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28. UPDATE request (S-CSCF to MRFC/AS) - see example in table A.3.2.2-28 

The S-CSCF forwards the UPDATE request to the MRFC/AS. 

Table A.3.2.2-28: UPDATE request (S-CSCF to MRFC/AS) 



UPDATE sip:conferencel@mrfcl .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 68 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length: 

v= 
o= 
s= 
c= 

t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 62 ETSI TS 1 24 1 47 V1 0.2.0 (201 2-01 ) 

29. 200 (OK) response (MRFC/ASto S-CSCF) - see example in table A.3.2.2-29 (related to table A.3.2.2-28) 

The MRFC/AS acknowledges the UPDATE request (27) with a 200 (OK) response. 

Table A.3.2.2-29: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

30. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in 
MRFP. 
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31. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.2-31 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.2.2-31 : 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 (OK) 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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32. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.2-32 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.2.2-32: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



33. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.3.2.2-33 (related to table A.3.2.2-9) 

After the success modification of the session (29), the MRFC/AS sends a 200 (OK) response final response 
to the INVITE request (8) to the I-CSCF. 

Table A.3.2.2-33: 200 (OK) response (MRFC/AS to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscfl.home2 .net;branch=z9hG4bK32f432 .1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact : <sip : conf erencelOmrf cl . home2 . net> ; isf ocus 

Allow-Events : conference, pending-additions 

Content-Length : 



Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages. 
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34. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.3.2.2-34 

The I-CSCF forwards the 200(OK) response to the S-CSCF 

Table A.3.2.2-34: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Content-Length: 



35. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.2.2-35 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.3.2.2-35: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Content-Length : 



36. Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12). 

37. 200 (OK) response (P-CSCF to UE) - see example in table A.3.2.2-37 

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the 
media flow(s) for this session. 

Table A.3.2.2-37: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow-Events : 

Content-Length : 
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38. ACK request (UE to P-CSCF) - see example in table A.3.2.2-38 

The UE starts the media flow for this session, and responds to the 200 (OK) response (32) with an ACK 
request sent to the P-CSCF. 

Table A.3.2.2-38: ACK request (UE to P-CSCF) 



ACK sip : conf erencelomrf cl . home2 . net 


SIP/2 


.0 












Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc 


ddd] : 


1357;comp=si 


gcomp ; 


oranch= 


z9hG4bKnas 


hds7 


Max- Forwards : 70 
















Route : <sip ipcscf 1 . visitedl .net : 7531; lr;c 


omp=sigcomp> 


, <sip 


:scscfl 


. home 1 


net 


;lr> 


From: <sip:userl publiclohomel . net> 


tag= 


171828 












To : <sip : conf erence-f actoryl@home2 .net>; t 


ag=314159 












Call -ID: Cb0 3a0s09a2sdfglkj4 903 3 3 
















Cseq: 127 ACK 
















Content-Length: 

















39. ACK request (P-CSCF to S-CSCF) - see example in table A.3.2.2-39 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.3.2.2-39: ACK request (P-CSCF to S-CSCF) 



ACK sip : conf erencelOmrf cl .home2 .net SIP/2.0 


Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 


Max- Forwards : 69 


Route : <sip : scscf 1 .homel .net; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length: 



40. ACK request (S-CSCF to MRFC/AS) - see example in table A.3.2.2-40 

The S-CSCF forwards the ACK request to the MRFC/AS. 

Table A.3.2.2-40: ACK request (S-CSCF to MRFC/AS) 



ACK sip : conf erence 


lOmrfcl . 


home 2 


.net SIP/2.0 








Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2 


0/UDP 


pcscfl .visitedl 


.net ;branch=z 


3hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc :ddd] 


:1357 


- comp= s igcomp ; b 


ranch= 


z9hG4bKnashds7 


Max-Forwards: 68 














From: 














To: 














Call-ID: 














Cseq: 














Content-Length: 















A.3.3 User automatically creating a conference with a conference 
URI 

The call flows for a user automatically creating a conference with a conference URI look identical to the call flows for 
conference creation with a conference-factory URI (see subclause A. 3. 2), besides the URls carried in the Request URI 
and Contact header fields. 
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A.3.4 User creating a conference by manually dialling 

The call flows for a user creating a conference by manually dialling into the IMS look identical to the call flows for 
conference creation with a conference-factory URI (see subclause A.3.2), besides the URIs carried in the Request URI 
and Contact header fields. 

A.3.5 User creating a conference from two existing connections 
(Three-way session), users in different networks 

Subclause 5.3.1.3.3 of the present document shows that the creation of a Three-way session is a local issue at the UE 
which results in a combination of other procedures (conference creation, conference participant invitation to conference, 
session release). 

A.3.6 User automatically creating a conference with a conference 
factory URI and inviting some users to the newly-created 
conference 

This flow shows how a user can create a conference using a conferece factory URI and simultaneously invite some 
users to the newly created conference, all using a single INVITE request. 
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Figure A.3.6-1 : User automatically creating a conference with a conference factory URI - MRFC/AS is 

located in user's home network 

Figure A.3.6-1 shows an user creating a conference by using a conference-factory URI and simultaneouslt inviting 
some users to that conference. The conference is created at a MRFC/AS of the users home network. 

The details of the flows are as follows: 

1 . INVITE request (UE to P-CSCF) - see example in table A.3.6-1 

A UE wants to create a conference. For this purpose the UE is aware of a conference-factory URI that was 
obtained by means outside the present document (e.g. due to pre-configuration or via other protocols, such as 
http). 

The UE wants also to invite some users to this conference in an expedite manner, avoiding the cumbersome 
manual invitation to each of these users. Thus it builds a URI list including the SIP URIs of the users that are 
to be invited and includes it in the message body of the INVITE request for conference creation. 
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That the invited users have previously given consent to the inviting user to invite them. 

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a 
SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for 
each possible media flow. Multiple media flows can be offered, and for each media flow (m= line in SDP), 
there can be multiple codec choices offered. 

For this example, it is assumed that the UE is willing to establish a multimedia session comprising an audio 
stream only. The audio stream supports the AMR codec. The UE sends the INVITE request to the P-CSCF. 

The UE indicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require' header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 
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Table A.3.6-1 : INVITE request (UE to P-CSCF) 



INVITE sip : conf erence-f actorylOmrf cl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig®scscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erence-f actorylOmrf cl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree, recipient-list-invite 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, application/3gpp-ims+xml 
Content - Type : mult ipart /mixed ; boundary= " boundaryl " 
Content-Length: (...) 

--boundaryl 

Content-Type: application/sdp 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 

--boundaryl 

Content-Type : application/resource-lists+xml 

Content -Disposition: recipient -list 

<?xml version="l . 0" encoding="UTF-8" ?> 

<resource- lists xmlns="urn: ietf :params :xml :ns : resource- lists" 
xmlns :cp="urn: ietf :params :xml :ns : copycontrol" > 
<list> 

<entry uri="sip :user2_publicl@homel .net" cp : copyControl="to" /> 
< entry uri="sip :user3_publicl@homel .net" cp : copyControl="to" 

cp : anonymize="true"/> 
< entry uri="sip :userl_publicl@foreign. com" cp : copyControl="to" 

cp : anonymize="true"/> 
</list> 
< /resource- list s> 
- -boundaryl- - 



Request-URI: contains the conference factory URL 

Content-Type: contains the specification of the MIME content with the string used as part separator 
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2. 100 (Trying) response (P-CSCF to UE) - see example in table A.3.6-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) provisional response. 

Table A.3.6-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 Trying 






Via: SIP/2. 0/UDP [5555: 


: aaa : bbb : ccc : ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


From: 






To: 






Call-ID: 






CSeq: 






Content-Length: 







3. INVITE request (P-CSCF to S-CSCF) - see example in table A.3.6-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 

Table A.3.6-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip : conference- factorylomrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Require: recipient-list-invite 
Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

--boundaryl 
Content-Type : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 

--boundaryl 
Content-Type : 
Content-Disposition : 

<?xml ...?> 
<resource-lists> 

< /resource- list s> 
--boundaryl 
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4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.3.6-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response. 

Table A.3.6-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP pcsc 


fl.visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] 


:1357; 


comp= 


=sigcomp 


;branch= 


z9hG4bKnashds7 




From: 






















To: 






















Call-ID: 






















CSeq: 
Content - 


Length: 





















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 
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6. INVITE request (S-CSCF to MRFC/AS) - see example in table A.3.6-6 

The S-CSCF forwards the INVITE request to the MRFC/AS that is indicated in the host part of the Request 
URI. The S-CSCF does not re-write the Request URL 

Table A.3.6-6: INVITE request (S-CSCF to MRFC/AS) 



INVITE sip : conference- factorylomrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip ipcscf 1 . visitedl .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Access-Network-Inf o : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig- 

ioi=typ3homel . net ; orig- ioi=homei . net 
P- Charging- Function-Addresses : ccf= [5555: :b99:c88:d77:e6 6] ; ccf=[5555: :a5 5:b44:c33:d22] 

ecf= [5555 : :lff :2ee:3dd:4cc] ; ecf= [5555 : : 6aa : 7bb : 8cc : 9dd] 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

Supported: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

--boundaryl 
Content-Type : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 

--boundaryl 
Content-Type : 
Content-Disposition: 

<?xml ...?> 
<resource-lists> 

< /resource- list s> 
--boundaryl 



7. 100 (Trying) response (MRFC/AS to S-CSCF) - see example in table A.3.6-7 (related to table A.3.6-6) 

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) provisional response. 
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Table A.3.6-7: 100 (Trying) response (MRFC/AS to S-CSCF) 



SIP/2.0 100 Trying 














Via: SIP/2 


.0/UDP scscfl.homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . 


visitedl 


net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: : 


aaa :bbb : ccc :ddd] :1357;comp= 


=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Le 


ngth : 















8. Allocate conference URI 

The MRFC/AS allocates a conference URI, based on local information and information gained from the 
conference-factory URI, as well as information gained from other elements of the SIP signalling. 

9. H.248 interaction to create connection 

The MRFC initiates a H.248 interaction to create an IMS connection point for UE#1 in MRFP and to 
determine media capabilities of the MRFP. 

10. Invite users to conference 

Once the conference URI is allocated the MRFC/AS checks that the the users identified by the SIP URIs in 
the body of the INVITE request from UE#1 have consented to be invited by UE#1. Provided they have 
previously consented, the users identified by the SIP URIs in the body of the INVITE request from UE#1 are 
invited to join the conference. To do this the MRFC/AS follows the procedure shown in A.4.3.1.3 setting the 
Request-URI to the users: sip:user2_publicl@homel.net, sip:user3_publicl@homel.net and 
sip: user l_publicl @foreign.net. 

Notice that the three invitations would be sent simultaneously if the MRFC/AS does support it (see section 
5.3.2.5.3). Notice also that it is not necessary that the MRFC/AS waits for the completion of the invitation 
procedures before continuing with step 11, i.e. the three invitations and the procedure being described in the 
present flow can run in parallel. 

1 1. 183 (Session Progress) response (MRFC/AS to S-CSCF) - see example in table A.3.6-13 (related to 
table A.3.6-6) 

The MRFC determines the complete set of codecs that it is capable of supporting for this conference. It 
determines the intersection with those appearing in the SDP in the INVITE request. 

The media stream capabilities of the destination are returned along the signalling path, in a 183 (Session 
Progress) provisional response (to 6). 
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Table A.3.6-10: 183 (Session Progress) response (MRFC/AS to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity : "Conference Server" <sip imrfcl .homel .net> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

orig-ioi=type3homel .net; term-ioi=homel .net; term-ioi=type3asl .net 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : e6 6] ; ccf = [5555 : : a5 5 : b44 : c3 3 : d22] ; 

ecf= [5555: :lff :2ee:3dd:4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: none 
From: 

To: <sip : conference-factorylOmrfcl .homel .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 

Contact : <sip : lmaa234269@mrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Contact: Contains the IP address or FQDN of the MRPC/AS and a temporary identifier of 

the conference being created in the user part. The URI for the allocated 
conference is not indicated yet. The "isfocus" feature parameter is included, as 
this temporary contact is still a conference URI. 

P-Charging- Vector: The MRFC/AS inserts this header and populates the icid parameters with a 

unique value and populates the term-ioi parameter with the identifier of its own 
network. 

P-Charging-Function-Address: The MRFC/AS stores the P-Charging-Function- Addresses header field to be 

passed to the S-CSCF. 

11. 183 (Session Progress) response (S-CSCF to P-CSCF) - see example in table A.3.6-11 

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 
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Table A.3.6-11 : 183 (Session Progress) response (S-CSCF to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc : ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e6 6]; ccf=[5555::a5 5:b44:c33:d22] 

ecf= [5 555: :lff :2ee:3dd:4cc] ; ecf= [5555: : Saa : 7bb : 8cc : 9dd] 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



12. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after the 200 (OK) response of INVITE request (39) based on operator local policy. 

13 183 (Session Progress) response (P-CSCF to UE) - see example in table A.3.6-13 

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint. 
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Table A.3.6-13: 183 (Session Progress) response (P-CSCF to UE) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip ipcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
a= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



14. Resource reservation 

The originating UE sets up the bearer in accordance with the media description received SDP. 

15. PRACK request (UE to P-CSCF) - see example in table A.3.6-15 

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 

Table A.3.6-15: PRACK request (UE to P-CSCF) 



PRACK sip: lmaa234269@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route: <sip :pcscfl .visitedl .net : 7531; lr;comp=sigcomp>, <sip : scscfl .homel .net ; lr> From: 

<sip : userl_publicl@homel . net> ; tag=171828 
To : <sip : conference -factorylOmrfcl .homel .net>; tag=314159 
Call-ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 128 PRACK 

Require: precondition, sec-agree 
Proxy-Require: sec-agree 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
RAck: 9021 127 INVITE 
Content-Length: 
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16. PRACK request (P-CSCF to S-CSCF) - see example in table A.3.6-16 

The P-CSCF forwards the PRACK request to the S-CSCF. 

Table A.3.6-16: PRACK request (P-CSCF to S-CSCF) 



PRACK sip: lmaa234269@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Inf o : 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
RAck: 
Content-Length : 



17. PRACK request (S-CSCF to MRFC/AS) - see example in table A.3.6-17 

The S-CSCF forwards the PRACK request to the MRFC/AS. 

Table A.3.6-17: PRACK request (S-CSCF to MRFC/AS) 



PRACK sip: lmaa234269@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1. homel. net ;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 .visitedl .net ;branch= 


=z9hG4bK240f34.: 


, SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc:ddd] 
Max- Forwards : 68 


1357;comp= 


=sigcomp. 


branch= 


z9hG4bKnashds7 


P-Access-Network-Info : 














From: 














To: 














Call-ID: 














Cseq: 
Require : 

RAck: 














Content-Length: 















18. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.3.6-18 (related to table A.3.6-17) 

The MRFC/AS acknowledges the PRACK request (17) with a 200 (OK) response. 

Table A.3.6-18: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 














Via: SIP/2. 0/UDP scscf 1. homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 .visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc:ddd] :1357;comp= 


=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 















19. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to modify the connection established in step #9 and instructs MRFP to 
reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation between 
the UE#1 and the MRFC. 
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20. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.6-20 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.6-20: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



21. 200 (OK) response (P-CSCF to UE) - see example in table A.3.6-21 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.6-21 : 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



22. UPDATE request (UE to P-CSCF) - see example in table A.3.6-22 

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the 
signalling path established by the INVITE request. 

Table A.3.6-22: UPDATE request (UE to P-CSCF) 



UPDATE sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip : pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erence-f actorylomrf cl .homel .net>; tag=314159 

Call -ID: Cb03a0s0 9a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telphone-event 
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23. UPDATE request (P-CSCF to S-CSCF) - see example in table A.3.6-23 

The P-CSCF forwards the UPDATE request to the S-CSCF. 

Table A.3.6-23: UPDATE request (P-CSCF to S-CSCF) 



UPDATE sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ; 

ggsn= [5555 : :4b4 :3c3 :2d2 : lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559 ; flow-id=3 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



24. UPDATE request (S-CSCF to MRFC/AS) - see example in table A.3.6-24 

The S-CSCF forwards the UPDATE request to the MRFC/AS. 

Table A.3.6-24: UPDATE request (S-CSCF to MRFC/AS) 



UPDATE sip: lmaa234269@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length: 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 81 ETSI TS 1 24 1 47 VI 0.2.0 (201 2-01 ) 

25. 200 (OK) response (MRFC/ASto S-CSCF) - see example in table A.3.6-25 (related to table A.3.6-24) 

The MRFC/AS acknowledges the UPDATE request (24) with a 200 (OK) response. 

Table A.3.6-25: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone -event 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

26. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in 
MRFP. 

27. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.6-27 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.3.6-27: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34 .1, SIP/2. 0/UDP 

[5555 : : aaa : bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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28. 200 (OK) response (P-CSCF to UE) - see example in table A.3.6-28 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.3.6-28: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



29. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.3.6-29 (related to table A.3.6-6) 

After the success modification of the session (26), the MRFC/AS sends a 200 (OK) response final response 
to the INVITE request (6) to the S-CSCF. 

Table A.3.6-29: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 
Allow-Events : conference, pending-additions 
Content-Length: 



Contact: Contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages 
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30. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.3.6-30 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.3.6-30: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow- Events : 
Content-Length : 



3 1 . Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12). 

32. 200 (OK) response (P-CSCF to UE) - see example in table A.3.6-32 

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the 
media flow(s) for this session. 

Table A.3.6-32: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow- Events : 

Content-Length : 



33. ACK request (UE to P-CSCF) - see example in table A.3.6-33 

The UE starts the media flow for this session, and responds to the 200( OK) response (32) with an ACK 
request sent to the P-CSCF. 

Table A.3.6-33: ACK request (UE to P-CSCF) 



ACK sip : conferencelOmrfcl .homel 


net:2342 


SIP/2 


.0 










Via: SIP/2. 0/UDP [5555: :aaa 


bbb 


ccc :ddd] 


:1357; 


comp=sigcomp; 


oranch= 


z9hG4bKnas 


tids7 


Max- Forwards : 7 


















Route: <sip :pcscfl .visitedl 


net 


7531; Ir; 


comp=sigcomp>, <sip 


: scscf 1 


.homel 


net 


; lr>From: 


<sip:userl publicl@homel 


net = 


; tag=171828 












To : <sip : conference -factorylOmrfcl .homel 


.net>; 


tag=314159 










Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 














Cseq: 127 ACK 


















Content-Length: 
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34. ACK request (P-CSCF to S-CSCF) - see example in table A.3.6-34 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.3.6-34: ACK request (P-CSCF to S-CSCF) 



ACK sip : conferencelOmrfcl .homel .net : 2342 SIP/2.0 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 


Max- Forwards : 69 


Route : <sip : scscf 1 .homel .net; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length: 



35. ACK request (S-CSCF to MRFC/AS) - see example in table A.3.6-35 

The S-CSCF forwards the ACK request to the MRFC/AS. 

Table A.3.6-35: ACK request (S-CSCF to MRFC/AS) 



ACK sip : conference 


lOmrfcl . 


homel 


.net:2342 SIP/2 









Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1. visitedl 


.net ;branch=z 


3hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc :ddd] 


:1357 


-comp=sigcomp;branch= 


z9hG4bKnashds7 


Max- Forwards : 68 














From: 














To: 














Call-ID: 














Cseq: 














Content-Length: 















A.4 Flows demonstrating a user joining a conference 
A.4.1 Introduction 

Void 
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A.4.2 User calling into a conference 

A.4.2.1 IVIRFC/AS is not located in user's home network 

A.4.2. 1 .1 Conference URI resolved by the terminating home network 



Visited Network 



UE#1 Home 
NetwDrl< 



MRFC/AS Home Network 



P-CSCF 



— 1. INVITE ► 

-2. 100 Trying 3. INVITE- 

< — 4. lOOTrying- 



5. Evaluation of initia 
Filter Criteria 



14. 183 Session 



15. Authorize QoS n 



16. 183 Session 



17. Resource 
Reservation 



—26. 200 OK— 
-27. UPDATE- 



39. Approval of QoS Commit 1 


< 40. 200 OK 




41.ACK *. 






42. ACK > 



— 6. INVITE 

-7. 100 Trying— 



■/ \ 

y a PSI location query 



_13. 183 Sessio 
Progress 



-12. 183 Session Progre 



-30. UPDATE- 
—31 . 200 OK— 



IVlRFC/AS IVlRFP 



1 1 . H.248 interaction to create 

;onference connection resources for 

UE#1 



23. H.248 interaction to modify 

:onference connection resources for 

UE#1 



32. H.248 interaction to connect 

ttirougli conference connection 

resources for UE#1 



Figure A.4.2. 1.1-1 : User calling into a conference - network MRFC/AS is not located in user's home 
network - conference URI resolved by the terminating home network 

Figure A.4.2. 1.1-1 shows an user calling into a conference by using a conference URI. The focus of that conference is at 
a MRFC/AS which are located in another network. The conference URI in this example cannot be resolved by the 
originating home network. 

The details of the flows are as follows: 

1. INVITE request (UE to P-CSCF) - see example in table A.4.2.1.1-1 

A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was 
obtained by means outside the present document (e.g. via other protocols, such as http). 

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a 
SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for 
each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), 
there may be multiple codec choices offered. 
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For this example, it is assumed that UE#1 is willing to establish a multimedia session comprising a video 
stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The 
audio stream supports the AMR codec.capable of sending two simultaneous video streams, either H261 or 
The UE sends the INVITE request to the P-CSCF. 

The UEindicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require' header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 



Table A.4.2.1.1-1: INVITE request (UE to P-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route: <sip :pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 

To: <sip : conf erencel@home2 .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8S42; port-s=7531 
Contact: <sip: userl_publicl@homel.net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 :: aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap : 99 : MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0, 2 , 5, 7; maxframes=2 

a = r tpmap :96 telephone- event 



Request-URI: contains the conference URL 
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2. 100 (Trying) response (P-CSCF to UE) - see example in table A.4.2.1.1-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response. 

Table A.4.2.1.1-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 (Trying) response 




Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





3. INVITE request (P-CSCF to S-CSCF) - see example in table A.4.2.1.1-3 

The P-CSCF forwards the INVITE request to the S-CSCF. 

Table A.4.2.1.1-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.1-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response. 

Table A.4.2.1.1-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP pcsc 


response 
f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] :1357; 


comp= 


=sigcomp 


;branch= 


z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF to I-CSCF) - see example in table A.4.2.1.1-6 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the INVITE request directly to the I-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 
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Table A.4.2.1.1-6: INVITE request (S-CSCF to l-CSCF) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. 100 (Trying) response (I-CSCF to S-CSCF) - see example in table A.4.2.1.1-7 (related to table A.4.2.1.1-6) 

The I-CSCF responds to the INVITE request (6) with a 100 (Trying) response provisional response. 

Table A.4.2.1.1-7: 100 (Trying) response (MRFC/AS to S-CSCF) 



SIP/2.0 100 (Trying) 


response 










Via: SIP/2 


.0/UDP scsc 


f 1 .homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . 


visitedl .net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


0/UDP 




[5555: : 


aaa :bbb : ccc 


:ddd] : 1357;comp=sigcomp;b 


ranch= 


29hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 














Content-Le 


ngth : 
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8. Public service identity (PSI) location query 

The I-CSCF sends a query to the HSS to find out the MRFC/AS at which the conference has been created. 
The HSS responds with the address of the MRFC/AS at which the conference is hosted. The HSS responds 
with the address of the MRFC/AS. 

For detailed message flows see 3GPP TS 29.228 [12]. 

Table A.4.2.1.1-8a provides the parameters in the SIP INVITE request, which are sent to the HSS. 

Table A.4.2.1.1-8a Cx: User location query procedure (I-CSCF to HSS) 



Message source and 
destination 


Cx: Information element 
name 


Information source in SIP 
INVITE 


Description 


I-CSCF to HSS 


Public Service Identity 
(PSI) 


Request-URI: 


This information element 
indicates the public user 
identity 



Table A.4.2.1.1-8b provides the parameters sent from the HSS that need to be mapped to SIP INVITE and 
sent to MRFC/AS. 

Table A.4.2.1.1-8b Cx: User location query procedure (HSS to I-CSCF) 



Message source and 
destination 


Cx: Information element 
name 


Mapping to SIP header in 
SIP INVITE 


Description 


HSS to I-CSCF 


MRFC/AS address 


IP packet destination 
address 


This information element indicates 
the IVIRFC/AS address which 
serves the PSI. 
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9. INVITE request (I-CSCF to MRFC/AS) - see example in table A.4.2.1.1-9 

I-CSCF forwards the INVITE request to the MRFC/AS that was resolved during the PSI location query (8). 
The I-CSCF does not re-write the Request URL 

Table A.4.2.1.1-9: INVITE request (I-CSCF to MRFC/AS) 



INVITE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. 100 (Trying) response (MRFC/AS to I-CSCF) - see example in table A.4.2.1.1-10 (related to table 
A.4.2.1.1-9) 

The MRFC/AS responds to the INVITE request (9) with a 100 (Trying) response provisional response. 
Table A.4.2.1.1-10: 100 (Trying) response (MRFC/AS to I-CSCF) 



SIP/2 . 100 (Trying) response 
Via: SIP/2. 0/UDP icscf2 s .home2 .net ;branch= 
scscfl. homel. net ;branch=z9hG4bK332b23.1, 


z9hG4bK871yl2.1, 
SIP/2. 0/UDP 


SIP/2. 


0/UDP 


pcscf 1 


visitedl .net ;branch=z 


3hG4bK240f34 


1, SIP/2. 0/UDP 






[5555: 


aaa:bbb:ccc:ddd] :1357 


-comp=sigcomp;branch=z9hG4bKnashds7 




From: 














To: 














Call-ID: 














CSeq: 

Content-Length: 
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1 1 . H.248 interaction to create conference connection resources for UE#1 

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP. 

12. 183 (Session Progress) response (MRFC/AS to I-CSCF) - see example in table A.4.2.1.1-12 (related to 
table A.4.2.1.1-9) 

The media stream capabilities of the conference are returned along the signalling path, in a 183 (Session 
Progress) provisional response (to 9). 

Table A.4.2.1.1-12: 183 (Session Progress) response (MRFC/AS to I-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2_s .home2 .net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 

[5555 : :aaa:bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net; lr> 
P-Asserted-Identity : "Conference Server" <sip :mrf cl .home2 .net> 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
P- Charging- Function-Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22]; 

ecf= [5555: :lff:2ee:3dd:4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: none 
From: 

To: <sip : conf erencel@home2 .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 
Contact : <sip : conf erencel@home2 . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 



Contact: Contains the conference URI for the conference allocated at the MRFC/AS and 

the "isfocus" feature parameter. 

P-Charging- Vector: The MRFC/AS inserts this header and populates the icid parameters with an 

unique value and the terminating Inter Operator Identifier (lOI) for the home 
network of the MRFC/AS and puts back the originating lOI. 

P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function- Addresses header field to 

be passed to the 1-CSCF. 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 93 ETSI TS 1 24 1 47 V1 0.2.0 (201 2-01 ) 

13. 183 (Session Progress) response (I-CSCF to S-CSCF) - see example in table A.4.2.1.1-13 

The I-CSCF forwards the 183 (Session Progress) response to the S-CSCF. 

Table A.4.2.1.1-13: 183 (Session Progress) response (I-CSCF to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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14. 183 (Session Progress) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.1-14 

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 

Table A.4.2.1.1-14: 183 (Session Progress) response (S-CSCF to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d77:e66] ; ccf=[5555: :a55:b44:c33:d22] 

ecf= [5555: :lff:2ee:3dd:4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



15. Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after 200 (OK) response of INVITE request (38) based on operator local policy. 
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16. 183 (Session Progress) response (P-CSCF to UE) - see example in table A.4.2.1.1-16 

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint. 

Table A.4.2.1.1-16: 183 (Session Progress) response (P-CSCF to UE) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:CCC:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



17. Resource reservation 

The originating UE sets up the bearer in accordance with the media description received SDP. 

18. PRACK request (UE to P-CSCF) - see example in table A.4.2.1.1-18 

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 1 96 ETSI TS 1 24 1 47 V1 0.2.0 (201 2-01 ) 

Table A.4.2.1.1-18: PRACK request (UE to P-CSCF) 



PRACK sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencel®home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 128 PRACK 

Require: precondition, sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
RAck: 9021 127 INVITE 
Content-Length: 



Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 
19. PRACK request (P-CSCF to S-CSCF) - see example in table A.4.2.1.1-19 

The P-CSCF forwards the PRACK request to the S-CSCF. 

Table A.4.2.1.1-19: PRACK request (P-CSCF to S-CSCF) 



PRACK sip : conf erencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
RAck: 
Content-Length : 



20. PRACK request (S-CSCF to I-CSCF) - see example in table A.4.2.1.1-20 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the PRACK request directly to the I-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 

Table A.4.2.1.1-20: PRACK request (S-CSCF to I-CSCF) 



PRACK sip : conf erencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57,-comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
RAck: 
Content-Length : 
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21. PRACK request (I-CSCF to MRFC/AS) - see example in table A.4.2.1.1-21 

I-CSCF forwards the PRACK request to the MRFC/AS that was resolved during the PSI location query (8). 

Table A.4.2.1.1-21 : PRACK request (I-CSCF to MRFC/AS) 



PRACK sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2_s . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 6 7 

From: 

To: 

Call-ID: 

Cseq: 

Require : 

RAck: 

Content-Length : 



22. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.4.2.1.1-22 (related to 
table A.4.2.1.1-21) 

The MRFC/AS acknowledges the PRACK request (21) with a 200 (OK) response. 
Table A.4.2.1.1-22: 200 (OK) response (MRFC/AS to I-CSCF) 



SIP/2.0 200 OK 














Via: SIP/: 


.0/UDP icscf 2 s. 


home 2 


. net ;branch= 


z9hG4bK871yl2.1, 


SIP/2. 


0/UDP 


scscf 1 


homel .net 


.-branch 


=z9hG4bK332b23 .1, 


SIP/2. 0/UDP 






pcscf 1 


visitedl 


net ;branch=z 


9hG4bK240f34 


1, SIP/2. 0/UDP 






[5555: 


aaa : bbb : ccc : ddd] 


:1357 


;comp=sigcomp;branch=z9hG4bKnashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 















23. H.248 interaction to modify connection for UE#1 

MRFC initiates a H.248 interaction to modify the connection established in step #1 1 and instructs MRFP to 
reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation 
between the UE#1 and the MRFC. 

24. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.4.2.1.1-24 

The I-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.2.1.1-24: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 














Via: SIP/: 


.0/UDP icscf 2 s. 


home 2 


. net ;branch= 


29hG4bK871yl2.1, 


SIP/2. 


0/UDP 


scscf 1 


homel .net 


/branch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 






pcscf 1 


visitedl . 


net ;branch=z 


3hG4bK240f34 


1, SIP/2. 0/UDP 






[5555: 


aaa : bbb : ccc : ddd] 


:1357 


-comp=sigcomp;branch=z9hG4bKnashds7 




From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 
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25. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.1-25 
S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.2.1.1-25: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 



26. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.1-26 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.4.2.1.1-26: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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27. UPDATE request (UE to P-CSCF) - see example in table A.4.2.1.1-27 

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the 
signalHng path estabUshed by the INVITE request. 

Table A.4.2.1.1-27: UPDATE request (UE to P-CSCF) 



UPDATE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencel@home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S17 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVPF 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVPF 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telphone-event 



Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 
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28. UPDATE request (P-CSCF to S-CSCF) - see example in table A.4.2.1.1-28 

The P-CSCF forwards the UPDATE request to the S-CSCF. 

Table A.4.2.1.1-28: UPDATE request (P-CSCF to S-CSCF) 



UPDATE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ; 

ggsn= [5555 : :4b4 :3c3 :2d2 : lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559 ; flow-id=3 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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29. UPDATE request (S-CSCF to I-CSCF) - see example in table A.4.2.1.1-29 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the UPDATE request directly to the I-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 

Table A.4.2.1.1-29: UPDATE request (S-CSCF to I-CSCF) 



UPDATE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 
pcscf 1 . visitedl . net ; branch=z9hG4bK24 0f 34 . 1 , SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content - Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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30. UPDATE request (I-CSCF to MRFC/AS) - see example in table A.4.2.1.1-30 

I-CSCF forwards the UPDATE request to the MRFC/AS that was resolved during the PSI location query (8). 
The I-CSCF does not re-write the Request URL 

Table A.4.2.1.1-30: UPDATE request (I-CSCF to MRFC/AS) 



UPDATE sip:conferencel@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 67 

From: 

To: 

Call-ID: 

Cseq: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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31. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.4.2.1.1-31 (related to 
table A.4.2.1.1-30) 

The MRFC/AS acknowledges the UPDATE request (30) with a 200 (OK) response. 
Table A.4.2.1.1-31 : 200 (OK) response (MRFC/AS to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

32. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in 
MRFP. 
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33. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.4.2.1.1-31 

The I-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.2.1.1-31 : 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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34. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.1-34 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.2.1.1-34: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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35. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.1-35 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.4.2.1.1-35: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



36. 200 (OK) response (MRFC/AS to I-CSCF) - see example in table A.4.2.1.1-36 (related to table A.4.2.1.1-9) 

After the success modification of the session (32), the MRFC/AS sends a 200 (OK) response final response 
to the INVITE request (9) to the I-CSCF. 

Table A.4.2.1.1-36: 200 (OK) response (MRFC/AS to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf2_s.home2 .net;branch=z9hG4bK871yl2 .1, SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net; lr> 

From: 

To: 

Call-ID: 

CSeq: 127 INVITE 

Contact : <sip : conf erencel@home2 . net> ; isf ocus 

Allow-Events : conference, pending-additions 

Content-Length: 



Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages 
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37. 200 (OK) response (I-CSCF to S-CSCF) - see example in table A.4.2.1.1-37 

The I-CSCF sends a 200 (OK) response final response along the signalling path back to the S-CSCF. 

Table A.4.2.1.1-37: 200 (OK) response (I-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Content-Length : 



38. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.1-38 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.4.2.1.1-38: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb: ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow-Events : 
Content-Length : 



39. Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (15). 

40. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.1-40 

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the 
media flow(s) for this session. 

Table A.4.2.1.1-40: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow-Events : 

Content-Length : 
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41. ACK request (UE to P-CSCF) - see example in table A.4.2.1.1-41 

The UE starts the media flow for this session, and responds to the 200( OK) response (40) with an ACK 
request sent to the P-CSCF. 

Table A.4.2.1.1-41 : ACK request (UE to P-CSCF) 



ACK sip :conferencel@home2 .net : 2342 SIP/2 















Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc 


ddd] 


1357;comp=si 


gcomp ; 


oranch= 


z9hG4bKnas 


hds7 


Max- Forwards : 70 
















Route : <sip ipcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp> 


, <sip 


:scscfl 


. home 1 


net 


;lr> 


From: <sip:userl publiclohomel . net> 


tag 


=171828 












To : <sip : conf erencel®home2 .net>; tag 


=314159 












Call -ID: Cb03a0s09a2sdfglkj 490333 
















Cseq: 127 ACK 
















Content-Length: 

















42. ACK request (P-CSCF to S-CSCF) - see example in table A.4.2.1.1-42 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.4.2.1.1-42: ACK request (P-CSCF to S-CSCF) 



ACK sip : conf erence 


1 ©home 2 . 


net:2342 SIP/2.0 










Via: SIP/2. 0/UDP p 


cscf 1 .visitedl 


net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555: :aaa:bbb: 


ccc :ddd] 


: 13 57;COmp= 


=sigcomp 


;branch=z9hG4bKnashds7 




Max- Forwards : 69 


















Route: <sip:scscfl 


.homel .net; lr> 














From: 


















To: 


















Call-ID: 


















Cseq: 


















Content-Length: 



















43. ACK request (S-CSCF to I-CSCF) - see example in table A.4.2.1.1-43 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the ACK request directly to the 1-CSCF in the destination 
network. 

As the S-CSCF does not know whether the I-CSCF at home2.net is a loose router or not, it does not introduce 
a Route header. 

Table A.4.2.1.1-43: ACK request (S-CSCF to I-CSCF) 



ACK sip : conf erence 


l@home2 . 


net 


2342 SIP/2.0 








Via: SIP/2. 0/UDP scscfl. homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscfl. visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc :ddd] 


: 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


Max-Forwards: 68 














From: 














To: 














Call-ID: 














Cseq: 














Content-Length: 
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44. ACK request (I-CSCF to MRFC/AS) - see example in table A.4.2.1.1-44 

I-CSCF forwards the ACK request to the MRFC/AS that was resolved during the PSI location query (8). The 
I-CSCF does not re-write the Request URL 

Table A.4.2.1.1-44: ACK request (I-CSCF to MRFC/AS) 



ACK sip : conf erencel@home2 . 


net:2342 SIP/2 . 








Via: SIP/2. 0/UDP icscf2_s. 


home2 . net ; branch= 


z9hG4bK871yl2.1, 


SIP/2. 


0/UDP 


scscf 1 .homel .net /branch 


=z9hG4bK332b23.1, 


SIP/2. 0/UDP 






pcscf 1 .visitedl .net ;branch=z9hG4bK240f 34 


1, SIP/2. 0/UDP 






[5555: : aaa : bbb : ccc : ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 




Max-Forwards: 67 










From: 










To: 










Call-ID: 










Cseq: 










Content-Length: 
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A.4.2.1 .2 Conference URI can be resolved by the originating home network 



Visited Network 



UE#1 Home 
Networl^ 



M RFC/AS Home Networl< 



UE#1 



P-CSCF 



S-CSCF 



IVIRFC/AS 



— 1. INViTE — 
-2. tOOTrying- 



— 3. iNVITE — 
-4. 1 00 Trying- 



5. Evaiuation of initiai 
Filter Criteria 



_10. 183Session_ 
Progress 



1 1 . Auttiorize QoS resources 



_12. 183Session_ 
Prog ress 



13. Resource 
Reservation 



-20. 200 OK— 
-21 . UPDATE- 



-15. PRACK- 



-22. UPDATE- 



-26. 200 OK- 



30. Approvai of QoS Commit 



-31 . 200 OK— 
—32. ACK M 



— 6. iNVITE — 
-7. lOOTrying- 



8. H.248 interaction to create 

conference connection resources for 

UE#1 



_9. 1 83 Session_ 
Progress 



-16. PRAGK- 
-17. 200OK- 



18. H.248 interaction to modify 

conference connection resources for 

UE#1 



-23. UPDATE- 



25. H.248 interaction to connect 

ttirough conference connection 

resources for UE#1 



-28. 200 OK- 



-34. ACK- 



Figure A.4.2.1. 2-1 : User calling into a conference - lUIRFC/AS is not located in user's home network - 
conference URI can be resolved by the originating home network 

Figure A. 4. 2. 1.2-1 shows an user calling into a conference by using a conference URL The focus of that conference is at 
a MRFC/AS which are located in another network. The conference URI in this example can be resolved by the 
originating home network. 

The details of the flows are as follows: 

1. INVITE request (UE to P-CSCF) - see example in table A.4.2.1.2-1 

A UE wants to join a conference. For this purpose the UE is aware of the related conference URI that was 
obtained by means outside the present document. 

The UE determines the complete set of codecs that it is capable of supporting for this conference. It builds a 
SDP Offer containing bandwidth requirements and characteristics of each, and assigns local port numbers for 
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each possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP), 
there may be multiple codec choices offered. 

For this example, it is assumed that UE#1 is willing to establish a multimedia session comprising a video 
stream and an audio stream. The video stream supports two codecs, either H.263 or MPEG-4 Visual. The 
audio stream supports the AMR codec. 

The UEindicates that it supports precondition and it indicates that it supports reliable provisional responses. 
However, it does not use the "Require' header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 



Table A.4.2.1.2-1 : INVITE request (UE to P-CSCF) 



INVITE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencelOmrf c2 . home2 . net> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-9S ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IPS 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap: 99 :MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



Request-URI: contains the conference URL 
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2. 100 (Trying) response (P-CSCF to UE) - see example in table A.4.2.1.2-2 

The P-CSCF responds to the INVITE request (1) with a 100 (Trying) response provisional response. 

Table A.4.2.1.2-2: 100 (Trying) response (P-CSCF to UE) 



SIP/2.0 100 (Trying) response 




Via: SIP/2. 0/UDP [5555: :aaa:bbb:ccc:ddd] 


: 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 


From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





3. INVITE request (P-CSCF to S-CSCF) - see example in table A.4.2.1.2-3 

The INVITE request is forwarded to the S-CSCF. 

Table A.4.2.1.2-3: INVITE request (P-CSCF to S-CSCF) 



INVITE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip :pcscf 1 . visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Contact : 
Allow: 
Accept : 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 
t= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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4. 100 (Trying) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.2-4 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) response provisional response. 

Table A.4.2.1.2-4: 100 (Trying) response (S-CSCF to P-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP pcsc 


response 
fl.visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555 


: : aaa :bbb : ccc 


:ddd] :1357; 


comp= 


=sigcomp 


;branch= 


z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 
Content - 


Length: 



















5. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. INVITE request (S-CSCF to MRFC/AS) - see example in table A.4.2.1.2-6 

S-CSCF forwards the INVITE request to the MRFC/AS based on the Request URI of the INVITE request. 
The S-CSCF does not re-write the Request URI. 
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Table A.4.2.1.2-6: INVITE request (S-CSCF to MRFC/AS) 



INVITE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c8 8 :d77 : e6 6] ; ccf = [5555 : : a5 5 : b44 : c3 3 : d22] ; 

ecf= [5555 : :lff :2ee:3dd:4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Supported: 

Contact : 

Allow: 

Accept : 

Content-Type : 

Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



7. 100 (Trying) response (MRFC/AS to S-CSCF) - see example in table A.4.2.1.2-7 (related to 
table A.4.2.1.2-6) 

The MRFC/AS responds to the INVITE request (6) with a 100 (Trying) response provisional response. 
Table A.4.2.1.2-7: 100 (Trying) response (MRFC/AS to S-CSCF) 



SIP/2.0 100 (Trying) 
Via: SIP/2. 0/UDP scsc 


response 
f 1 .homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1. 


visitedl .net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: : 


aaa :bbb : ccc 


:ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 














To: 














Call-ID: 














CSeq: 
Content-Le 


ngth : 













8. H.248 interaction to create conference connection resources for UE#1 

MRFC initiates a H.248 interaction to create an connection point for UE#1 in MRFP. 
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9. 183 (Session Progress) response (MRFC/AS to S-CSCF) - see example in table A.4.2.1.2-9 (related to table 
A.4.2.1.2-6) 

The media stream capabilities of the conference are returned along the signalling path, in a 183 (Session 
Progress) provisional response (to 6). 

Table A.4.2.1.2-9: 183 (Session Progress) response (MRFC/AS to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
P-Asserted-Identity : "Conference Server" <sip imrfcl .homel .net> 
P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term- ioi=home2 . net 
P- Charging- Function-Addresses : ccf= [5555 : :b99 : c88 :d77 : eSS] ; ccf = [5555 : : a5 5 : b44 : c3 3 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: none 
From: 

To: <sip : conf erencel@mrf c2 .home2 .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 

Contact : <sip : conf erencelomrf c2 . home2 . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 :: 1111 : 2222 : 3333 : 4444 

s = - 

C = IN IP6 5555 : :1111:2222 :3333 :4444 

t = 

m=video 10001 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 6544 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Contact: Contains the conference URI for the conference allocated at the MRFC/AS and 

the "isfocus" feature parameter. 

P-Charging- Vector: The MRFC/AS inserts this header and populates the icid parameters with an 

unique value and the terminating Inter Operator Identifier (lOI) for the home 
network of the MRFC/AS and puts back the originating lOI. 

P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function- Addresses header field to 

be passed to the S-CSCF. 
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10. 183 (Session Progress) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.2-10 

The S-CSCF forwards the 183 (Session Progress) response to the P-CSCF. 

Table A.4.2.1.2-10: 183 (Session Progress) response (S-CSCF to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d77:e66] ; ccf=[5555: :a55:b44:c33:d22] 

ecf= [5555: :lff:2ee:3dd:4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



1 1 . Authorize QoS Resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after 200( OK) response to the INVITE request (30) based on operator local policy. 



£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 10 117 ETSI TS 1 24 1 47 VI 0.2.0 (201 2-01 ) 

12. 183 (Session Progress) response (P-CSCF to UE) - see example in table A.4.2.1.2-12 

The P-CSCF forwards the 183 (Session Progress) response to the originating endpoint. 

Table A.4.2.1.2-12: 183 (Session Progress) response (P-CSCF to UE) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:CCC:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp> 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

RSeq: 

Content-Type : 

Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



13. Resource reservation 

The originating UE sets up the bearer in accordance with the media description received SDP. 

14. PRACK request (UE to P-CSCF) - see example in table A.4.2.1.2-14 

The PRACK request does not carry SDP as the final codec decision is already made as part of the initial 
offer/answer exchange. 
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Table A.4.2.1.2-14: PRACK request (UE to P-CSCF) 



PRACK sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip:pcscf 1 . visitedl .net : 75 31; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencelomrf c2 . home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 128 PRACK 

Require: precondition, sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
RAck: 9021 127 INVITE 
Content-Length: 



Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 
15. PRACK request (P-CSCF to S-CSCF) - see example in table A.4.2.1.2-15 

The P-CSCF forwards the PRACK request to the S-CSCF. 

Table A.4.2.1.2-15: PRACK request (P-CSCF to S-CSCF) 



PRACK sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2 . 0/UDP 

[5 555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 
P-Access-Network-Inf o : 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Require: precondition 
RAck: 
Content-Length : 



16. PRACK request (S-CSCF to MRFC/AS) - see example in table A.4.2.1.2-16 

S-CSCF forwards the PRACK request to the MRFC/AS based on the Request URI of the PRACK request. 
The S-CSCF does not re-write the Request URI. 

Table A.4.2.1.2-16: PRACK request (S-CSCF to MRFC/AS) 



PRACK sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 
Require : 
RAck: 
Content-Length : 
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17. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.4.2.1,2-17 (related to 
table A.4.2.1.2-16) 

The MRFC/AS acknowledges the PRACK request (16) with a 200 (OK) response. 
Table A.4.2.1.2-17: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 












Via: SIP/2. 0/UDP scscfl.homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf l.visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc:ddd] : 1357;comp=sigcomp;b 


ranch= 


z9hG4bKnashds7 


From: 












To: 












Call-ID: 












CSeq: 












Content-Length: 













18. H.248 interaction to modify connection for UE#1 

MRFC initiates a H.248 interaction to modify the connection established in step #1 1 and instructs MRFP to 
reserve the multimedia processing resources for UE#1 according to the preceding resource negotiation 
between the UE#1 and the MRFC. 

19. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.2-19 

S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.2.1.2-19: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




















Via: SIP/2. 0/UDP 


pcsc 


f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555: :aaa:bbb 


: ccc 


:ddd] 


:1357; 


::omp= 


=sigcomp 


;branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















CSeq: 




















Content-Length: 





















20. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.2-20 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.4.2.1.2-20: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 :: aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 
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21. UPDATE request (UE to P-CSCF) - see example in table A.4.2.1.2-21 

When the resource reservation is completed, the UE sends the UPDATE request to the MRFC/AS, via the 
signalling path established by the INVITE request. 

Table A.4.2.1.2-21 : UPDATE request (UE to P-CSCF) 



UPDATE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Access -Network- Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=2 34151D0FCEll 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : conf erencelomrf c2 . home2 . net> ; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 12 9 UPDATE 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933S17 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telphone-event 



Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 
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22. UPDATE request (P-CSCF to S-CSCF) - see example in table A.4.2.1.2-22 

The P-CSCF forwards the UPDATE request to the S-CSCF. 

Table A.4.2.1.2-22: UPDATE request (P-CSCF to S-CSCF) 



UPDATE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Max- Forwards : 69 
P-Access-Network-Info : 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=02 3 551024" ; 

ggsn= [5555 : :4b4 :3c3 :2d2 : lei] ; pdp-sig=no; gcid=723084371; auth-token=43876559 ; flow-id=3 
Route : <sip : scscf 1 . homel . net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 
t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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23. UPDATE request (S-CSCF to MRFC/AS) - see example in table A.4.2.1.2-23 

S-CSCF forwards the UPDATE request to the MRFC/AS based on the Request URI of the UPDATE request. 
The S-CSCF does not re-write the Request URI. 

Table A.4.2.1.2-23: UPDATE request (S-CSCF to MRFC/AS) 



UPDATE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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24. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.4.2.1.2-24 (related to 
table A.4.2.1.2-23) 

The MRFC/AS acknowledges the UPDATE request (23) with a 200 (OK) response. 
Table A.4.2.1.2-24: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555 :: aaa : bbb : ccc : ddd 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5, 7; maxframes=2 

a=rtpmap:96 telephone-event 



The SDP indicates that the resource reservation was successful both in the local and the remote segment. 

25. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#1 in 
MRFP. 
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26. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.2-26 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.2.1.2-26: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5 555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
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27. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.2-27 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.4.2.1.2-27: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



28. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.4.2.1.2-28 (related to table A.4.2.1.2-7) 

After the success modification of the session (25), the MRFC/AS sends a 200 (OK) response final response 
to the INVITE request (6) to the I-CSCF. 

Table A.4.2.1.2-28: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
From: 
To: 

Call-ID: 

CSeq: 127 INVITE 

Contact : <sip : conf erencelOmrf c2 . home2 . net> ; isf ocus 
Allow-Events : conference , pending-additions 
Content-Length: 



Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event packages 
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29. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.2.1.2-29 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to the P-CSCF. 

Table A.4.2.1.2-29: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb: ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Allow- Events : 
Content-Length : 



30. Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (14). 

31. 200 (OK) response (P-CSCF to UE) - see example in table A.4.2.1.2-31 

The P-CSCF forwards the 200 (OK) response final response to the session originator. The UE can start the 
media flow(s) for this session. 

Table A.4.2.1.2-31 : 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip : pcscf 1 .visitedl .net : 75 31; lr;comp=sigcomp> 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Allow- Events : 

Content-Length : 



32. ACK request (UE to P-CSCF) - see example in table A.4.2.1.2-32 

The UE starts the media flow for this session, and responds to the 200 (OK) response (31) with an ACK 
request sent to the P-CSCF. 

Table A.4.2.1.2-32: ACK request (UE to P-CSCF) 



ACK sip : conferencel®mrfc2 .home2 .net : 2342 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip : pcscf 1 .visitedl .net : 7531; Ir ; comp=sigcomp> , <sip:scscfl .homel .net ; lr> 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To : <sip : conf erencelomrf c2 . home2 . net> ; tag=314159 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 ACK 

Content-Length: 



Cseq: is required to be the same value as Cseq contained in original INVITE request (3). 
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33. ACK request (P-CSCF to S-CSCF) - see example in table A.4.2.1.2-33 

The P-CSCF forwards the ACK request to the S-CSCF. 

Table A.4.2.1.2-33: ACK request (P-CSCF to S-CSCF) 



ACK sip : conferencel@mrfc2 .home2 .net : 2342 SIP/2.0 


Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 


[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 


Max- Forwards : 69 


Route : <sip : scscf 1 .homel .net; lr> 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length: 



34. ACK request (S-CSCF to MRFC/AS) - see example in table A.4.2.1.2-34 

S-CSCF forwards the ACK request to the MRFC/AS based on the Request URI of the ACK request. The S- 
CSCF does not re-write the Request URI. 

Table A.4.2.1.2-34: ACK request (S-CSCF to MRFC/AS) 



ACK sip : conference 


l@mrfc2 .home2 


.net:2342 SIP/2 


.0 






Via: SIP/2. 0/UDP scscf 1. homel. net ;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 .visitedl 


.net ;branch=z 


9hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb: 


ccc:ddd] :1357 


;comp=sigcomp;branch= 


z9hG4bKnashds7 


Max- Forwards : 6 8 












From: 












To: 












Call-ID: 












Cseq: 












Content-Length: 













A.4.3 User getting invited to a conference 

A.4.3.1 IVIRFC/AS is not located in user's home network 

A.4.3. 1 .1 Conference Participant referring another user to a conference 

Figure A.4.3. 1.1-1 shows how UE#1 refers UE#2 to a conference. UE#1 has created a conference by using the 
mechanisms described in subclause 6.2, and UE#1 has learned the conference URI that identifies this conference. 
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Visited Networl< 



UE#1 Home Networl< 



UE#2 Home Networl< 



UE#1 



P-CSCF#1 



S-CSCF#1 



IVIRFC/AS 



l-CSCF#2 



1 . UE#1 creates a conference 



-2. REFER- 



-10. 202 Accepted - 



-13. NOTIFY- 
-14. 200OK- 



-20. NOTIFY— 
-21. 200 OK ► 



-3. REFER- 



4. Evaluation of initial 
Filter Criteria 



-9. 202 Accepted 



-12. NOTIFY 



-15. 200 OK > 



-19. NOTIFY 



-22. 200 OK 



-6. REFER- 

7. 202 

Accepted 




Figure A.4.3. 1.1-1: User inviting another user to a conference by 
sending a REFER request to the other user 

The details of the flows are as follows: 

1 . UE#1 creates a conference 

UE#1 creates a conference as described in subclause 6.3.2. Once the conference creation is accomplished, 
UE#1 has learned the conference URI allocated for this conference. 
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2. REFER request (UE to P-CSCF) - see example in table A.4,3.1.1-2 

A UE has created a conference and learned the conference URL Now the UE wants to invite another UE to 
that conference. 

Table A.4.3.1.1-2: REFER request (UE to P-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To : <sip : user2_publicl@home2 . net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 REFER 

Require: sec -agree 

Refer-To : <sip : conf erencelomrf cl . homel . net ;method=INVITE> 

Referred- By : <sip :userl_publicl@homel .net> 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Content-Length: 



Request-URI: contains the pubHc user identity of UE#2. 

Via: contains the IP address or FQDN of the originating UE. 

Refer-To: contains the conference URI as learned during the conference establishment. Additionally the 

"method" uri parameter indicates that the other user is requested to send an INVITE request to this 
conference URI. 

Referred-By: contains the public user identity of the referring user, as in this example the referring user has 
decided to indicate its own identity to the referred user. 

3. REFER request (P-CSCF to S-CSCF) - see example in table A.4.3.1.1-3 

The P-CSCF forwards the REFER request to the S-CSCF. 

Table A.4.3.1.1-3: REFER request (P-CSCF to S-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : :aaa :bbb: ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 69 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip : pcscf 1 .visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P- Charging- Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=123551024" 
P-Access-Network-Inf o : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Referred-By: 
Supported: 
Contact : 
Content-Length : 
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4. Evaluation of initial Filter Criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

5. REFER request (S-CSCF to I-CSCF in UE#2 home network) - see example in table A.4.3.1.1-5 

The S-CSCF performs an analysis of the destination address, and determines the network operator to whom 
the destination subscriber belongs. Since the originating operator does not desire to keep their internal 
configuration hidden, the S-CSCF forwards the REFER request directly to the destination network. 

Table A.4.3.1.1-5: REFER request (S-CSCF to I-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Supported: 
Contact : 
Content-Length : 



6. REFER request (I-CSCF towards S-CSCF of UE#2) - see example in table A.4.3.1.1-6 

The I-CSCF performs a Cx location query to the HSS (not shown in this flow) to find out the S-CSCF of 

UE#2. 

The I-CSCF then forwards the REFER request to that S-CSCF that will handle the session termination. 
Table A.4.3.1.1-6: REFER request (I-CSCF towards S-CSCF of UE#2) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 

Route : <sip : scscf 2 . home2 . net ; lr> 
Record-Route : 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Supported: 
Contact : 
Content-Length : 
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7. 202 (Accepted) response (S-CSCF of UE#2 to I-CSCF) - see example in table A.4.3.1.1-7 

UE#2 home network indicates that it has received the REFER request by sending a 202 (Accepted) response. 
This means that UE#2 home network has begun to process the request. This does not mean, however, that the 
referred-to resource would have been contacted. 

Table A.4.3.1.1-7: 202 (Accepted) response (S-CSCF of UE#2 to I-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP icscf 2 . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip : pcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net ; lr>, 
<sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; icid-generated- 
at= [5555 : : f 5f :e4e :d3d:c2c] ; orig- ioi=homel .net; term-ioi=home2 .net 

P- Charging- Function-Addresses : ccf = [5555 : :b99 : c88 :d77 : eS6] ; ccf = [5555 : : a55 :b44 : c33 :d22] 
ecf= [5555: :lff :2ee:3dd:4cc] ; ecf= [5555: : 6aa : 7bb : Scc : 9dd] 

Privacy : none 

From: <sip : userl_publicl@homel . net> ; tag=171828 

To : <sip : user2_publicl@home2 . net> ; tag=151170 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 127 REFER 

Contact :user2_publicl@home2 .net ;gr=urn:uuid: 2ad895 0e-4 8a5-4a74-8d99- 
ad76cc7f c74 ;comp=sigcomp> 

Content-Length : 



202 (Accepted) response (I-CSCF to S-CSCF) - see example in table A.4.3.1.1-8 

The I-CSCF forwards the response to the S-CSCF. 

Table A.4.3.1.1-8: 202 (Accepted) response (I-CSCF to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; ; orig-ioi=homel .net; 

term- ioi=home2 . net 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 



202 (Accepted) response (S-CSCF to P-CSCF) - see example in table A.4.3.1.1-9 

The S-CSCF forwards the response to the P-CSCF. 

Table A.4.3.1.1-9: 202 (Accepted) response (S-CSCF to P-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscfl. visitedl. net;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

[5555 : :aaa:bbb:ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+S02IrT5tAFrbHLso=123551024" 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 
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10. 202 (Accepted) response (P-CSCF to UE#1) - see example in table A.4.3.1.1-10 

The P-CSCF forwards the response to the UE. 

Table 6.3.3.1-10: 202 (Accepted) response (P-CSCF to UE#1) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net : 7531; lr;comp=sigcomp> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length: 



1 1 . NOTIFY request (from S-CSCF of UE#2 to S-CSCF) - see example in table A.4.3.1.1-11 

S-SCSF receives a NOTIFY request corresponding the REFER request. The NOTIFY request contains 
information about the progress of the REFER request processing. The body of the NOTIFY request contains 
a fragment of the response as received by the notifying UE for the request that was initiated due to the 
REFER request. The NOTIFY request is forwarded to the P-CSCF. 

Table A.4.3.1.1-11 : NOTIFY request (from S-CSCF of UE#2 to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP scscf2 .home2 .net;branch= z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=home2 .net 
Max- Forwards : 68 

Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
To: <sip :userl_publicl@homel .net>; tag=17182 8 
From: <sip : user2_publicl@home2 . net >;tag=15 1170 
Call-ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 42 NOTIFY 

Subscript ion- St ate : active; expires : 72 
Event: refer 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 100 (Trying) response 
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12. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A.4.3.1.1-12 

The S-CSCF forwards the message to the P-CSCF. 

Table: A.4.3.1.1-12: NOTIFY request (from S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK23436s . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 .0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" 
P- Charging- Function-Addresses : ccf = [5555: :b99:c88:d77:e66] ; ccf=[5555: :a55:b44:c33:d22] 

ecf= [5555: :lff:2ee:3dd:4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Max- Forwards : 67 

Route : <sip :pcscf 1 . visitedl .net ; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 



13. NOTIFY request (from P-CSCF to UE#1) - see example in table A.4.3.1.1-13 

The P-CSCF forwards the message to UE#1. 

Table A.4.3.1.1-13: NOTIFY request (from P-CSCF to UE#1) 



NOTIFY sip: [5555 : :aaa:bbb:CCC:ddd] :1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl .net : 7531;comp=sigcomp;branch=z9hG4bK23433 . 1, SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK23436s.l, SIP/2 . 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max- Forwards : 66 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 
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14. 200 (OK) response (UE to P-CSCF) - see example in table A.4.3.1.1-14 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.4.3.1.1-14: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP pcscfl .visitedl . net : 7531 ; comp=sigcomp;branch=z9hG4bK23433 . 1 , 


SIP/2. 0/UDP 


scscfl.homel.net;branch=z9hG4bK23436s.l, SIP/2. 0/UDP 




scscf2.home2.net;branch=z9hG4bK764z87.1, SIP/2. 0/UDP 




pcscf2 .visited2 .net;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 




[5555 : :eee: f f f :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 




P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





15. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.1-15 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.1-15: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 








Via: SIP/2. 0/UDP scscfl.homel 


net;branch=z9hG4bK23436s.l, 


SIP/2. 0/UDP 


scscf 2 .home2 .net /branch 


=z9hG4bK764z87.1, SIP/2 . 0/UDP 




pcscf2 .visited2 .net ;branch= 


=z9hG4bK234223.1, SIP/2. 0/UDP 




[5555: :eee:fff :aaa:bbb] 


: 88 05;comp=sigcomp;branch=z9hG4bK23dh42 . 1 


P-Access-Network-Info : 








P-Charging-Vector : icid-va 


lue= 


="AyretyUOdm+602IrT5tAFrbHLso 


=223551024" 


From: 








To: 








Call-ID: 








CSeq: 








Content-Length: 









16. 200 (OK) response (S-CSCF to S-CSCF of UE#2) - see example in table A.4.3.1.1-16 

The S-CSCF forwards the 200 (OK) response to the S-CSCF of UE#2 according to the information in the Via 
field. 

Table A.4.3.1.1-16: 200 (OK) response (S-CSCF to S-CSCF of UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=homel .net; 

term- ioi=homel . net 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



17. UE#2 joins the conference. 

UE#2 joins the conference. The message flows are depicted in subclause 6.3.2. 
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18. NOTIFY request (from S-CSCF of UE#2 to S-CSCF) - see example in table A.4.3.1.1-18 

S-SCSF receives a NOTIFY request corresponding the REFER request. 

Table A.4.3.1.1-18: NOTIFY request (from S-CSCF of UE#2 to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK23d244 . 1 , SIP/2. 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=323551024" ; orig-ioi=home2 .net 

Max- Forwards : 6 8 

Route : <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net; lr> 

To: <sip :userl_publicl@homel .net>; tag=171828 

From: <sip : user2_publicl®home2 . net >;tag=15 1170 

Call -ID: Cb03a0s09a2sdfglkj 490333 

CSeq: 43 NOTIFY 

Subscription-State: terminated 

Event : refer 

Content-Length: (...) 

Content-Type: message/sipf rag 

SIP/2.0 200 OK 



Subscription-State: indicates that the impHcit subscription to the refer event has been terminated. 
19. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A.4.3.1.1-19 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.4.3.1.1-19: NOTIFY request (from S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK23436s . 1 , SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK23d244 .1, SIP/2 .0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P- Charging Vector: icid-value="AyretyUOdm+602IrT5tAFrbHLso=323 551024" 
P- Charging- Function- Addresses : ccf=[5555::b99:c88:d77:e66]; ccf=[5555::a5 5:b44:c33:d22] 

ecf= [5555: :lff:2ee:3dd:4cc] ; ecf=[5555: : 6aa : 7bb : 8cc : 9dd] 
Max- Forwards : 6 7 

Route : <sip :pcscf 1 .visitedl .net ; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 
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20. NOTIFY request (from P-CSCF to UE#1) - see example in table A.4.3.1.1-20 

The P-CSCF forwards the NOTIFY request to UE#1. 

Table A.4.3.1.1-20: NOTIFY request (from P-CSCF to UE#1) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net : 7531 ; comp=sigcomp;branch=z9hG4bK23433 . 1 , SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK23436s.l, SIP/2 .0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK23d244 .1, SIP/2 .0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max-Forwards: 66 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



21. 200 (OK) response (UE to P-CSCF) - see example in table A.4.3.1.1-21 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.4.3.1.1-21 : 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl.visitedl.net :7531;comp=sigcomp;branch=z9hG4bK23433 .1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK23436s.l, SIP/2 . 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK23d244 .1, SIP/2 . 0/UDP 

pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



22. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.1-22 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.1-22: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK23436s.l, SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK23d244 .1, SIP/2 .0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 

P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024" 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 
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23. 200 (OK) response (S-CSCF to S-CSCF of UE#2) - see example in table A.4.3.1.1-23 

The S-CSCF forwards the 200 (OK) response to the home network of UE#2 according to the information in 
the Via field. 



Table A.4.3.1.1-23: 200 (OK) response (S-CSCF to S-SCSF of UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK23d244 .1, SIP/2 . 0/UDP 

pcscf2 .visited2 .net;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024" ; orig-ioi=homel .net; 

term-ioi=homel .net 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



A.4.3.1 .2 User getting referred to a conference by a conference participant 

Figure A.4.3.1.2-1 shows how UE#2 gets referred to a conference by receiving a REFER request from a conference 
participant. The REFER request contains the conference URI where UE#2 should use when joining the conference. 



UE#1 Home Network 



UE#2 Home Network 



UE#2 Visited Network 



IVIRFC/AS 



l-CSCF 



-1. REFER- 



S-CSCF 



2.HSS query 



-10. 202 Accepted - 



-13. NOTIFY 
-14. 200 OK- 



17. UE#2 joins the 
conference 



-20. NOTIFY 
-21. 200 OK- 



-3. REFER- 



P-CSCF 



4. Evaluation of 
initial Filter Criteria 



-9. 202 Accepted- 



-5. REFER- 



-8. 202Accepted- 



-12. NOTIFY- 



-15. 200 OK ► 



UE#2 



-6. REFER- 



-7. 202 Accepted— 



-11. NOTIFY - 



-16. 200OK- 



17. UE#2 joins the conference 



-19. NOTIFY- 



-22. 200 OK ► 



-18. NOTIFY - 



-23. 200 OK ► 



Figure A.4.3.1.2-1 : User getting invited to a conference by receiving a REFER request. 
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The details of the flows are as follows: 

1. REFER request (S-CSCF of UE#1 to I-CSCF) - see example in table A.4.3.1.2-1 

REFER request is sent by the S-CSCF of UE#1 to UE#2 home network. S-SCSF of UE#1 has resolved the 
address of I-CSCF as the entry point to UE#2 home network. See subclause 6.3.3.1.1 for originating side of 
the call flow. 

Table A.4.3.1.2-1 : REFER request (S-CSCF of UE#1 to I-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 8 

Record- Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 
P-Asserted-Identity: "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig-ioi=homel .net 
Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171828 
To : <sip : user2_publicl@home2 . net> 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 127 REFER 

Refer-To : <sip : conf erencelOmrf cl . homel . net ;method=INVITE> 
Referred- By : <sip :userl_publicl@homel .net> 
Supported: gruu 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Content-Length: 



Request-URI: contains the public user identity of UE#2. 

Refer-To: contains the conference URI as learned during the conference establishment. Additionally the 

"method" uri parameter indicates that the other user is requested to send an INVITE request to this 
conference URI. 

Referred-By: contains the public user identity of the referring user, as in this example the referring user has 
decided to indicate its own identity to the referred user. 

2. The I-CSCF performs HSS query 

The I-CSCF performs HSS query to find out the S-CSCF serving UE#2. 
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3. REFER request (I-CSCF to S-CSCF) - see example in table A.4.3.1.2-3 

After finding out the S-CSCF assigned to UE#2, the I-CSCF forwards the REFER request to that S-CSCF. 
The I-CSCF does not add itself to the Record-route since it does not have to remain on the signalling path for 
subsequent requests within the same dialog. 

Table A.4.3.1.2-3: REFER request (I-CSCF to S-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK871yl2 . 1, SIP/2. 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 67 
Record-Route : 

Route : <sip : scscf 2 . home2 . net ; lr> 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=123551024" ; orig-ioi=homel .net 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By 
Supported: 
Contact : 
Content-Length : 

(...) 



4. Evaluation of initial Filter Criteria 

The S-CSCF validates the service profile of this subscriber, and evaluates the initial Filter Criteria. 

5. REFER request (S-CSCF to P-CSCF) - see example in table A.4.3.1.2-5 

The S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the 
P-CSCF assigned for UE#2 and routes the REFER request there. 

Table A.4.3.1.2-5: REFER request (S-CSCF to P-CSCF) 



REFER sip: [5555 : : eeee : f f f f :aaaa:bbbb] : 88 05 ; comp = sigcomp SIP/2 . 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK234974 . 3 , SIP/2 . 0/UDP 

icscf2.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 66 
Record-Route : <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> , 

<sip : pcscf 1 .visitedl .net; lr> 
Route: <pcscf 2 . visited2 .net ; lr> 
P-Asserted- Identity : 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=123551024" 
P-Charging Function-Addresses: ccf = [5555 : :b99 : c88 :d77 : e66] ; ccf = [5555 : : a55 :b44 : c33 : d22] 

ecf= [5555: : If f :2ee : 3dd: 4cc] ; ecf = [5555 : : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Supported: 
Contact : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 
Content-Length : 

(...) 
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6. REFER request (P-CSCF to UE#2) - see example in table A.4.3.1.2-6 

The P-CSCF forwards the request to UE#2. 

Table A.4.3.1.2-6: REFER request (P-CSCF to UE#2) 



REFER sip: [5555 : : eeee : f f f f :aaaa:bbbb] : 88 05 ; comp=sigcomp SIP/2 . 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK249354 . 1 , SIP/2 . 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK234974 .3, SIP/2 .0/UDP 

icscf2.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 6 5 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Supported: 
Contact : 

P-Called-Party-ID: 
Content-Length : 

(...) 



7. 202 (Accepted) response (UE#2 to P-CSCF) - see example in table A.4.3.1.2-7 

UE#2 accepts the REFER request by sending a 202 (Accepted) response. 

Table A.4.3.1.2-7: 202 (Accepted) response (UE#2 to P-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf2 .visited2 .net :5088;comp=sigcomp;branch=z9hG4bK249354 .1, SIP/2 . 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK234974 .3, SIP/2 .0/UDP 

icscf2.home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 . 0/UDP 

scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip: scscfl .homel .net; lr>, <sip : pcscf 1 .visitedl .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy=none 
From: 

To : <sip : user2_publicl@home2 . net> ; tag=151170 
Call-ID: 
CSeq: 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

; comp=sigcomp> 
Content-Length : 
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8. 202 (Accepted) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.2-8 

The P-CSCF forwards the 202 (Accepted) response to the S-CSCF. 

Table A.4.3.1.2-8: 202 (Accepted) response (P-CSCF to S-CSCF) 



SIP/2.0 202 Accepted 

Via: scscf2 .home2 .net;branch=z9hG4bK234974 .3, SIP/2. 0/UDP 
icscf2 .home2 .net ;branch=z9hG4bK871yl2 .1, SIP/2 .0/UDP 
scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 
pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr>, 
<sip:scscfl .homel .net; lr>, <sip ipcscf 1 .visitedl .net; lr> 

P-Asserted-Identity : "John Smith" <sip :user2_publicl@home2 .net 

P-Access-Network-Info : 

P- Charging- Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=12 3 551024" 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length: 



202 (Accepted) response (S-CSCF to I-CSCF) - see example in table A.4.3.1.2-9 

The S-CSCF forwards the 202 (Accepted) response to the I-CSCF. 

Table A.4.3.1.2-9: 202 (Accepted) response (S-CSCF to I-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP icscf 2 . home2 . net ;branch=z9hG4bK871yl2 . 1 , SIP/2. 0/UDP 

scscfl. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig-ioi=home2 .net 

term-ioi=visited2 .net 
P- Charging- Function-Addresses : ccf= [5555 : :b99 : c8 8 : d77 : e6 6] ; ccf = [5555 : : a5 5 : b44 : c3 3 : d22] ; 

ecf= [5555: : If f : 2ee : 3dd : 4cc] ; ecf= [5555: : 6aa : 7bb : 8cc : 9dd] 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length: 
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10. 202 (Accepted) response (I-CSCF to UE#1 home network) - see example in table A.4.3.1.2-10 

The I-CSCF forwards the 202 (Accepted) response to S-CSCF of UE#1. 

Table A.4.3.1.2-10: 202 (Accepted) response (I-CSCF to S-CSCF of UE#1) 



SIP/2.0 202 Accepted 

Via: scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

pcscf 1 .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 5 7;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" ; orig-ioi=home2 .net 

term-ioi=visited2 .net 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length: 



1 1. NOTIFY request (from UE#2 to P-CSCF) - see example in table A.4.3.1.2-11 

UE#2 creates a subscription and sends a notification of the status of the refer event. 

Table A.4.3.1.2-11 : NOTIFY request (from UE#2 to P-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max-Forwards: 70 
Route: <sip : pcscf 2 .home2 .net :5088;lr>,<sip:scscf2 .home2 .net;lr>, <sip:scscfl .homel .net ; lr>, 

<sip : pcscf 1 .visitedl .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
To: <sip :userl_publicl@homel .net>; tag=17182 8 
From: <sip : user2_publicl@home2 . net >;tag=15 1170 
Call-ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 42 NOTIFY 

Subscript ion- St ate : active /expires : 72 
Event: refer 
Contact : <sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-48a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 100 (Trying) response 



12. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A.4.3.1.2-12 

The P-CSCF forwards the NOTIFY request to the S-CSCF. 
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Table: A.4.3.1.2-12: NOTIFY request (from P-CSCF to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK234223 . 1 , SIP/2. 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max-Forwards: 69 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" 

Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, <sip :pcscf 1 . visitedl .net ; lr> 
P-Access-Network-Info : 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 



13. NOTIFY request (from S-CSCF to UE#1 home network) - see example in table A.4.3.1.2-13 

The S-CSCF forwards the NOTIFY request to UE#1 home network (S-CSCF#1). 

Table A.4.3.1.2-13: NOTIFY request (from S-CSCF to UE#1 home network) 



NOTIFY sip: userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-00a0c91e6bf 6 
;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK764z87 . 1 , SIP/2 . 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=home2 .net 

Max- Forwards : 6 8 

Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 

To: 

From: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Contact : 

Content-Length: (...) 

Content-Type : 

(...) 



14. 200 (OK) response (S-CSCF of UE#1 to S-CSCF) - see example in table A.4.3.1.2-14 

The S-CSCF receives a 200 (OK) response to the NOTIFY request from UE#rs home network. 

Table A.4.3.1.2-14: 200 (OK) response (S-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87.1, SIP/2 . 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=223551024" ; orig-ioi=home2 .net 
term- ioi=homel . net 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



15. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.3.1.2-15 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 
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Table A.4.3.1.2-15: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK234223 . 1, SIP/2. 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+SO2IrT5tAFrbHLso=22 3 5 51024" 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 



16. 200 (OK) response (P-CSCF to UE#2) - see example in table A.4.3.1.2-16 

The P-CSCF forwards the 200 (OK) response to UE#2. 

Table A.4.3.1.2-16: 200 (OK) response (P-CSCF to UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



17. UE#2 joins the conference. 

UE#2 joins the conference. The message flows are depicted in subclause 6.3.2. 

18. NOTIFY request (from UE#2 to P-CSCF) - see example in table A.4.3.1.2-18 

P-SCSF receives a NOTIFY request from UE#2 indicating the status of the refer event. 

Table A.4.3.1.2-18: NOTIFY request (from UE#2 to P-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max-Forwards: 70 
Route : <sip : pcscf 2 . visited2 .net:5088;lr>,<sip:scscf2 .home2 .net ; lr>, 

<sip:scscfl .homel .net; lr>, <sip:pcscfl . visitedl .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
To: <sip :userl_publicl@homel .net>; tag=171828 
From: <sip :user2_publicl@home2 . net >;tag=15 117 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 43 NOTIFY 

Subscription-State: terminated 
Event : refer 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 200 OK 



19. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A,4,3.1.2-19 

The P-CSCF forwards the NOTIFY request to the S-CSCF. 
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Table A.4.3.1.2-19: NOTIFY request (from P-CSCF to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP pcscf2 .visited2 .net;branch=z9hG4bK234223 .1, SIP/2. 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=323551024" 
Max-Forwards: 69 

Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr>, <sip :pcscf 1 . visitedl .net ; lr> 
P-Access-Network-Inf o : 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



20. NOTIFY request (from S-CSCF to S-CSCF of UE#1) - see example in table A.4.3.1.2-20 

The S-CSCF forwards the NOTIFY request to UE#rs home network. 

Table A.4.3.1.2-20: NOTIFY request (from S-CSCF to S-CSCF of UE#1) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 
;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK23d244 . 1 , SIP/2. 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805;comp = sigcomp;branch=z9hG4bK23dh42 . 1 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=323551024" ; orig-ioi=home2 .net 

Max-Forwards: 68 

Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net; lr> 

To: 

From: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Length: (...) 

Content-Type : 

(...) 



21. 200 (OK) response (S-CSCF of UE#1 to S-CSCF) - see example in table A.4.3.1.2-21 

The S-CSCF receives a 200 (OK) response to the NOTIFY request from UE#1 home network. 

Table A.4.3.1.2-21 : 200 (OK) response (S-CSCF of UE#1 to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK23d244 .1, SIP/2 . 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=323551024" ; orig-ioi=homel .net 
term- ioi=homel . net 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



22. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.2-22 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 
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Table A.4.3.1.2-22: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 .net ;branch=z9hG4bK234223 . 1, SIP/2. 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=32 3 5 51024" 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 



23. 200 (OK) response (P-CSCF to UE#2) - see example in table A.4.3.1.2-23 

The P-CSCF forwards the 200 (OK) response to UE#2. 

Table A.4.3.1.2-23: 200 (OK) response (P-CSCF UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



A.4.3.1 .3 MRFC/AS invites a user to a conference 

Figure A.4.3.1.3-1 shows an MRFC/AS inviting a user to a conference. The invitation is sent as a result of 

userl @homel.net sending a REFER request to the MRFC/AS. The MRFC/AS is located in a different network than 

user's S-CSCF. 
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Figure A.4.3. 1.3-1 : MRFC/AS inviting a user to a conference - lUIRFC/AS routes directly to l-CSCF 
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The details of the flows are as follows: 

1. INVITE request (MRFC/AS to I-CSCF) - see example in table A.4.3.1.3-1 

In this example, the MRFC/AS is capable of resolving the terminating users I-CSCF address for this request. 
As a result of a DNS query, it has received the address of the I-CSCF as the next hop. 

The MRFC/AS invites a user to a conference as it received a REFER request from another user. 

The MRFC/AS determines the codecs that are applicable for this conference. It builds a SDP Offer 
containing bandwidth requirements and characteristics of each, and assigns local port numbers for each 
possible media flow. Multiple media flows may be offered, and for each media flow (m= line in SDP). In this 
example, there is only one codec per media offered. 

For this example, it is assumed that MRFC/AS is willing to establish a multimedia session comprising a 
video stream and an audio stream. The video stream supports H.263. The audio stream supports the AMR 
codec. 

The MRFC/AS indicates that it supports precondition and it indicates that it supports reliable provisional 
responses. However, it does not use the "Require' header for these capabilities. 

The UE does not have available the resources that are necessary to transport the media. 

For this example it is assumed, that signalling encryption was negotiated between UE and P-CSCF in the 
security mode set-up procedure during the last successful authentication. This option will only be shown in 
this example. 
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Table A.4.3.1.3-1 : INVITE request (MRFC/AS to l-CSCF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP mrf cl . homel . net ;branch=z9hG4bK23273846 

Max- Forwards : 7 

P-Asserted- Identity : <sip : conference lOmrfcl .homel .net> 

P-Charging-Vector: #### 

Privacy: none 

From: <sip : conf erencelomrf cl .homel .net>; tag=17182 8 

To : <sip :user2_publicl@home2 .net> 

Call -ID: Cb03a0s09a2sdfglkj4 90333 

Cseq: 127 INVITE 

Supported: precondition, lOOrel 

Referred- By : <sip :userl_publicl@homel .net> 

Contact : <sip : conf erencelomrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 

Allow-Events : conference, pending-additions 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933S15 IN IP6 5555 : : abc : def : abc : abc 

s = - 

c = IN IP6 5555 : :abc:def :abc:def 

t = 

m=video 10001 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



Request-URI: contains the public user identity of UE#2. 

P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS. 

Contact: contains the conference URI for the conference allocated at the MRFC/AS and the 

"isfocus" feature parameter. 

Allow-Events: The MRFC/AS indicates support for the "conference" and "pending-additions" event 

packages 

Referred-By: contains the same value as received in the Referred-By in the REFER request that was 

received from the user that requested the MRFC/AS send the INVITE request. 

2. 100 (Trying) response (I-CSCF to MRFC/AS) - see example in table A.4.3.1.3-2 

The I-CSCF responds to the INVITE request with a 100 (Trying) provisional response. 

Table A.4.3.1.3-2: 100 (Trying) response (I-CSCF to MRFC/AS) 



SIP/2.0 100 Trying 
Via: SIP/2. 0/UDP conf 


erence 


lOmrf cl 


homel 


net 


branch= 


=z9hG4bK23273846 


From: 
















To: 
















Call-ID 
















CSeq: 

Content - 


Length: 
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3. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [12]. 

4. INVITE request (I-CSCF to S-CSCF) - see example in table A.4.3.1.3-4 

The INVITE request is forwarded to the S-CSCF. 

Table A.4.3.1.3-4: INVITE request (I-CSCF to S-CSCF) 



INVITE sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Max- Forwards : 69 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Ref erred-By : 
Contact : 
Allow: 

Allow- Events : 
Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



5. 100 (Trying) response (S-CSCF to I-CSCF) - see example in table 6.2.2.2-5 

The S-CSCF responds to the INVITE request (3) with a 100 (Trying) provisional response. 

Table 6.2.2.2-5: 100 (Trying) response (S-CSCF to I-CSCF) 



SIP/2.0 100 Trying 

Via: SIP/2. 0/UDP icscf 2 . home2 . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK2 32 73 84 6 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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6. Evaluation of initial filter criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

7. INVITE request (S-CSCF to P-CSCF) - see example in table A.4.3.1.3-7 

S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the P-CSCF 
assigned for UE#2 and routes message there. 

Table A.4.3.1.3-7: INVITE request (S-CSCF to P-CSCF) 



INVITE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 .0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max-Forwards: 68 

Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector: #### 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Ref erred-By : 
Contact : 
Allow: 

Allow-Events : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 
Content-Type : 
Content-Length: (...) 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



8. 100 (Trying) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.3-8 

The P-CSCF responds to the INVITE request (6) with a 100 (Trying) provisional response. 
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Table A.4.3.1.3-8: 100 (Trying) response (P-CSCF to S-CSCF) 



SIP/2.0 100 Trying 




Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK332b23 . 1, 


SIP/2. 0/UDP 


icscf2.home2.net;branch=z9hG4bK241dl7.2, SIP/2. 0/UDP 




mrfcl.homel.net;branch=z9hG4bK23273846 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





9. INVITE request (P-CSCF to UE#2) - see example in table A.4.3.1.3-9 
P-CSCF forwards the request to UE#2. 

Table A.4.3.1.3-9: INVITE request (P-CSCF to UE#2) 



INVITE sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 6 7 

Record- Route : <sip :pcscf 2 . visited2 .net : 50 88 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 

Supported: 
Ref erred-By : 
Contact : 
Allow: 

Allow-Events : 
P-Called-Party-ID: 
Content-Type : 
Content-Length: (...) 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



10. 100 (Trying) response (UE#2 to P-CSCF) - see example in table A.4.3.1.3-10 

UE#2 responds to the INVITE request (9) with a 100 (Trying) provisional response. 
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Table A.4.3.1.3-10: 100 (Trying) response (UE#2 to P-CSCF) 



SIP/2.0 100 Trying 
















Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch= 


z9hG4bK240f34 


1 SIP/2 


0/UDP 


scscf 2 . home2 . net 


;branch= 


=z9hG4bK332b23 .1, 


SIP/2 


0/UDP 








icscf 2 . home2 . net 


;branch= 


=z9hG4bK241dl7.2, 


SIP/2 


0/UDP 








mrf cl . homel . net ; 


oranch=z9hG4bK2 32 73 84 6 












From: 
















To: 
















Call-ID: 
















CSeq: 
















Content-Length: 

















1 1. 183 (Session Progress) response (UE#2 to P-CSCF) - see example in table A.4.3.1.3-11 

UE#2 determines the complete set of codecs that it is capable of supporting for this session. It determines the 
intersection with those appearing in the SDP in the INVITE request. 

The UE responds with a 183 (Session Progress) response containing SDP back to the originator. This 
response is sent to the P-CSCF. 

Table A.4.3.1.3-11: 183 (Session Progress) response (UE#2 to P-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip : pcscf 2 . visited2 .net : 5088 ; Ir ; comp=sigcomp> , <sip:scscf2 .home2 .net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy: none 
From: 

To: <sip :user2_publicl@home2 .net>; tag=314159 
Call-ID: 
CSeq: 

Require: precondition, lOOrel 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad7Scc7f c74 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
RSeq: 9021 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933623 IN IP6 5555 : : eee : f f f : aaa :bbb 

s = - 

c = IN IP6 5555 : :eee:fff :aaa:bbb 

t = 

m=video 34 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=inactive 

a=conf:qos remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 
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12. Authorize QoS resources 

The P-CSCF authorizes the resources necessary for this session. The approval of QoS commitment either 
happens at this stage or after 200 (OK) response of INVITE request (31) based on operator local policy. 

13. 183 (Session Progress) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.3-13 

The P-CSCF forwards the 183 (Session Progress) response to the S-CSCF. 

Table A.4.3.1.3-13: 183 (Session Progress) response (P-CSCF to S-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr> 
P-Asserted-Identity : "John Smith" <sip :user2_publicl@home2 .net> 
P-Access-Network-Info : 
P-Charging-Vector: #### 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content -Length: 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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14. 183 (Session Progress) response (S-CSCF to I-CSCF) - see example in table A.4.3.1.3-14 

The S-CSCF forwards the 183 (Session Progress) response to I-CSCF. 

Table A.4.3.1.3-14: 183 (Session Progress) response (S-CSCF to I-CSCF) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net>, <tel : +l-212-555-2222> 
P-Charging-Vector: #### 
P-Charging-Function-Addresses : #### 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Require : 
Contact : 
Allow: 
RSeq: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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15. 183 (Session Progress) response (I-CSCF to MRFC/AS) - see example in table A.4.3.1.3-15 

The I-CSCF forwards the 183 (Session Progress) response to the MRFC/AS. 

Table A.4.3.1.3-15: 183 (Session Progress) response (I-CSCF to MRFC/AS) 



SIP/2.0 183 Session Progress 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 

Record-Route : 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Require : 

Contact : 

Allow: 

RSeq: 

Content-Type : 

Content - Length : 

v= 
o= 
s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 



16. PRACK request (MRFC/AS to S-CSCF) - see example in table A.4.3.1.3-16 

The MRFC/AS determines which media flows should be used for this session, and which codecs should be 
used for each of those media flows. 

Since there is no change in the media characteristics, the MRFC/AS does not include any new SDP offer in 
the PRACK request sent to UE#2. 

The MRFC/AS sends the PRACK request to the S-CSCF of UE#2 according to the Record-Route header 
received in 183 Session progress (15). 
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Table A.4.3.1.3-16: PRACK request (MRFC/AS to S-CSCF) 



PRACK sip:user2 publicl@home2.net 


gr=urn 


:uuid 


:2ad8950e- 


48a5 


-4a74 


-8d99 


-ad76 


cc7fc74 


;comp=sigcomp SIP/2.0 




















Via: SIP/2. 0/UDP mrfcl.homel 


net ;branch= 


z9hG4bK23273846 












Max- Forwards : 70 




















Route: <sip : scscf 2 .home2 .net 


lr>, 


<sip:p 


-scf2 


.visited2 


net; 


lr> 








From: <sip : conf erencel@mrf cl 


homel .net>; 


tag= 


171828 












To: <sip:user2 publicl@home2 


net> 


tag=314159 














Call -ID: Cb03a0s09a2sdfglkj 490333 


















Cseq: 128 PRACK 




















RAck: 9021 127 INVITE 




















Content-Length: 





















Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 

17. Resource reservation 

After determining the media streams, the MRFC/AS initiates the reservation procedures for the resources 
needed for this session. 

18. PRACK request (S-CSCF to P-CSCF) - see example in table A.4.3.1.3-18 

The P-CSCF forwards the PRACK request to the P-CSCF. 

Table A.4.3.1.3-18: PRACK request (S-CSCF to P-CSCF) 



PRACK sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 69 

Route : <sip :pcscf 2 . visited2 .net ; lr> 
From: 
To: 

Call-ID: 
Cseq: 
RAck: 
Content-Length : 



19. PRACK request (P-CSCF to UE#2) - see example in table A.4.3.1.3-19 

The P-CSCF forwards the PRACK request to UE#2. 

Table A.4.3.1.3-19: PRACK request (P-CSCF to UE#2) 



PRACK sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf2.visited2 .net :5088;comp=sigcomp;branch=z9hG4bK240f34 .1, SIP/2. 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
Cseq: 
RAck: 
Content-Length : 



20. 200 (OK) response (UE#2 to P-CSCF) - see example in table A.4.3.1.3-20 (related to table A.4.3.1.3-19) 

UE#2 acknowledges the PRACK request (19) with a 200 (OK) response. 
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Table A.4.3.1.3-20: 200 (OK) response (UE#2 to P-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5 088 ;comp=sigcomp;branch=z9hG4bK24 0f 34 . 1, 


SIP/2. 0/UDP 


scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 




mrfcl.homel.net;branch=z9hG4bK23273846 




P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





21. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.3-21 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.3-21 : 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 



22. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.4.3.1.3-22 

The S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.4.3.1.3-22: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrfcl. homel. net;branch=z9hG4bK23273846 

P-Access-Network-Info : 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 
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23. UPDATE request (MRFC/AS to S-CSCF) - see example in table A.4.3.1.3-23 

When the resource reservation in step (17) is completed, the MRFC/AS sends the UPDATE request to UE#2. 

Table A.4.3.1.3-23: UPDATE request (MRFC/AS to S-CSCF) 



UPDATE sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 
Max- Forwards : 70 

Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
From: <sip : conf erencel@mrf cl .homel .net>; tag=171828 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj 490333 
Cseq: 12 9 UPDATE 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933617 IN IP6 5555 : : abc : def : abc : abc 

s = - 

c = IN IP6 5555 : :abc:def :abc:def 

t = 

m=video RTP/AVP 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 



Request-URI: takes the value of the Contact header of the received 183 (Session Progress) response. 
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24. UPDATE request (S-CSCF to P-CSCF) - see example in table A.4.3.1.3-24 

The S-CSCF forwards the UPDATE request to the P-CSCF. 

Table A.4.3.1.3-24: UPDATE request (S-CSCF to P-CSCF) 



UPDATE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Max- Forwards : 69 

Route : <sip :pcscf 2 . visited2 .net; lr> 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length: 

v= 
o= 
s= 
c= 

t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
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25. UPDATE request (P-CSCF to UE#2) - see example in table A.4.3.1.3-25 

The P-CSCF forwards the UPDATE request to UE#2. 

Table A.4.3.1.3-25: UPDATE request (P-CSCF to UE#2) 



UPDATE sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 68 
From: 
To: 

Call-ID: 
Cseq: 

Content-Type : 
Content-Length: 

v= 
o= 
s= 
c= 

t= 

m= 
m= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
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26. 200 (OK) response (UE#2 to P-CSCF) - see example in table A.4.3.1.3-26 (related to table A.4.3.1.3-25) 

UE#2 acknowledges the UPDATE request (25) with a 200 (OK) response. 

Table A.4.3.1.3-26: 200 (OK) response (UE#2 to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933623 2987933625 IN IP6 5555:: aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video RTP/AVPF 98 

b=AS:75 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVPF 97 96 

b=AS:2 5.4 

a=curr:qos local sendrecv 

a=curr:qos remote sendrecv 

a=des:qos mandatory local sendrecv 

a=des:qos mandatory remote sendrecv 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone -event 
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27. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.3-27 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.3-27: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 .home2 .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 

Content-Type : 
Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
a= 
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28. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.4.3.1.3-28 

The S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.4.3.1.3-28: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 

From: 

To: 

Call-ID: 

CSeq: 

Content-Type : 

Content-Length : 

v= 
o= 

s= 
c= 

t= 

m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 
m= 
b= 
a= 
a= 
a= 
a= 
a= 
a= 



29. H.248 interaction to modify connection 

MRFC initiates a H.248 interaction to connect through the multimedia processing resources for UE#2 in 
MRFP. 

30. 200 (OK) response (UE#2 to P-CSCF) - see example in table A.4.3.1.3-30 (related to table A.4.3.1.3-9) 

UE#2 sends a 200 (OK) response final response to the INVITE request (9) to the P-CSCF. 

Table 6.2.2.2-30: 200 (OK) response (UE#2 to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK240f 34 . 1 SIP/2. 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip :pcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 

CSeq: 12 7 INVITE 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Content-Length: 



3 1 . Approval of QoS commit 

The P-CSCF approves the commitment of the QoS resources if it was not approved already in step (12). 
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32. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.3-32 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.3-32: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip ipcscf 2 . visited2 .net; lr>, <sip:scscf2 .home2 .net; lr> 
P-Access-Network-Inf o : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length: 



33. 200 (OK) response (S-CSCF to I-CSCF) - see example in table A.4.3.1.3-33 

The S-CSCF sends a 200 (OK) response final response along the signalling path back to I-CSCF. 

Table A.4.3.1.3-33: 200 (OK) response (S-CSCF to I-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP icscf 2 .home2 .net ;branch=z9hG4bK241dl7 . 2 , SIP/2. 0/UDP 

mrfcl. homel. net ;branch=z9hG4bK23273846 
Record-Route : 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 



34. 200 (OK) response (I-CSCF to MRFC/AS) - see example in table A.4.3.1.3-34 

The I-CSCF forwards the 200 (OK) response final response to the session originator. 

Table 6.2.2.2-34: 200 (OK) response (I-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrfcl. homel. net;branch=z9hG4bK23273846 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 
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35. ACK request (MRFC/AS to S-CSCF) - see example in table A.4,3.1.3-35 

The MRFC/AS responds to the 200 (OK) response (35) with an ACK request sent to the S-CSCF. 

Table A.4.3.1.3-35: ACK request (MRFC/AS to S-CSCF) 



ACK sip: user2_publicl@home2 .net ;gr=urn:uuid: 2ad8 95 0e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP mrf cl . homel . net ;branch=z9hG4bK23273846 
Max- Forwards : 70 

Route : <sip:scscf2 .home2 .net; lr>, <sip:pcscf2 . visited2 .net; lr> 
From: <sip : conferencel@mrfcl .homel .net>; tag=171828 
To : <sip : user2_publicl@home2 . net> ; tag=314159 
Call -ID: Cb03a0s09a2sdfglkj49033 3 
Cseq: 127 ACK 
Content-Length: 



36. ACK request (S-CSCF to P-CSCF) - see example in table A.4.3.1.3-36 

The S-CSCF forwards the ACK request to the P-CSCF. 

Table A.4.3.1.3-36: ACK request (S-CSCF to P-CSCF) 



ACK sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf2.home2.net;branch=z9hG4bK332b23.1, 


SIP/2. 0/UDP 


mrf cl. homel. net ;branch=z9hG4bK23273846 




Max- Forwards : 69 




Route : <sip:pcscf 2 . visited2 .net; lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





37. ACK request (P-CSCF to UE#2) - see example in table A.4.3.1.3-37 

The P-CSCF forwards the ACK request to the UE#2. 

Table A.4.3.1.3-37: ACK request (P-CSCF to UE#2) 



ACK sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp=sigcomp SIP/2.0 






Via: SIP/2 . 0/UDP pcscf2 .visited2 .net : 5088 ; comp=sigcomp;branch= 


z9hG4bK240f34.1, 


SIP/2. 0/UDP 


scscf2.home2.net;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 






mrf cl. homel. net ;branch=z9hG4bK23273846 






Max-Forwards: 68 






From: 






To: 






Call-ID: 






Cseq: 






Content-Length: 







A.4.3.1 .4 MRFC/AS refers a user to a conference 

Figure A.4.3.1.4-1 shows how MRFC/AS refers UE#2 to a conference by sending a REFER request to UE#2.The 
MRFC/AS has created a conference and allocated a conference URL 

In this example, the MRFC/AS is not capable of resolving the Request-URI and therefore routes the request first to the 
S-CSCF in its own network. 
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MRFC/AS network 



UE#2 Home Network 



UE#2 Visited Network 









MRFC/AS 




S-CSCF 



-1. REFER > 



f-12. 202 Accepted — 

[ 16. NOTIFY 

17. 200 OK ► 



l-CSCF 



-2. REFER > 



S-CSCF 



3. HSS query 



-11.202 Accepted— 



-4. REFER > 



P-CSCF 



5. Evaluation of 
initial Filter Criteria 



-10. 202 Accepted - 



-15. NOTIFY - 



-18. 200 OK- 



-6. REFER ► 



-9. 202 Accepted- 



-14. NOTIFY - 



-19. 200OK- 



UE#2 



-7. REFER > 



-8. 202 Accepted- 



-13. NOTIFY - 



-20 200 OK ► 



21 UE#2 joins conference 



-25. NOTIFY- 
-26. 200OK- 



-24. NOTIFY- 



-27. 200 OK- 



-23. NOTIFY- 



-28. 200 OK- 



-22. NOTIFY - 



-29. 200 OK- 



Figure A.4.3. 1.4-1 : MRFC/AS inviting another user to a conference by 
sending a REFER request to UE#2 
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The details of the flows are as follows: 

1. REFER request (MRFC/AS to S-CSCF) - see example in table A.4.3.1.4-1 

The MRFC/AS wants to invite another user to a conference by sending a REFER request to that user. 

Table A.4.3.1.4-1 : REFER request (MRFC/AS to S-CSCF) 



REFER sip: user2_publicl@home2.net SIP/2.0 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 

Max- Forwards : 70 

Route : <sip : scscf 1 . homel . net ; lr> 

P-Asserted- Identity : <sip : conf erencelOmrf cl .homel .net> 

P-Charging-Vector: #### 

Privacy: none 

From: <sip : conf erencelOmrf cl .homel .net>; tag=171828 

To : <sip :user2_publicl@home2 .net> 

Call -ID: Cb0 3a0s0 9a2sdfglkj4 90333 

Cseq: 127 REFER 

Refer-To : <conf erencelOmrf cl . homel . net ;method=INVITE> 

Referred- By : <sip :userl_publicl@homel .net> 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 

Content-Length: 



Request-URI: contains the public user identity of UE#2. 

P-Asserted-Identity: contains the asserted identity as configured in the MRFC/AS. 

P-Charging- Vector: the MRFC/AS inserts this header and populates the icid parameters with a globally unique 

value and includes the originating network identifier. 

Refer-To: contains the conference URL Additionally the method uri parameter indicates that the 

UE#2 shall send an INVITE request to this URI. 

Referred-By: contains the public user identity of the user, on which behalf the MRFC/AS sends the 

REFER message. 

Contact: contains the conference URI for the conference allocated at the MRFC/AS and the 

"isfocus" feature parameter. 

2. REFER request (S-CSCF to I-CSCF) - see example in table A.4.3.1.4-2 

The REFER request is forwarded to the I-CSCF. 

Table A.4.3.1.4-2: REFER request (S-CSCF to I-CSCF) 



REFER sip:user2_publiclOhome2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfcl. homel. net ;branch=z9hG4bK23273846 
Max- Forwards : 6 9 

Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : <sip : conf erencelOmrf cl .homel .net> 
P-Charging-Vector : 
Privacy: 
From : 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Referred-By: 
Contact : 
Content-Length : 
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3. Cx: User Location Query procedure 

The I-CSCF sends a query to the HSS to find out the S-CSCF of the called user. The HSS responds with the 
address of the current S-CSCF for the terminating subscriber. 

For detailed message flows see 3GPP TS 29.228 [12] 



4. REFER request (I-CSCF to S-CSCF) - see example in table A.4.3.1.4-4 

The I-CSCF forwards the REFER request to the address obtained during HSS query. The I-CSCF adds itself 
to the Via, but not to the Record-Route header as it will not need to stay on the signalling path for subsequent 
requests. 

Table A.4.3.1.4-4: REFER request (I-CSCF to S-CSCF) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP icscf2 .home2 .net;branch=z9hG4bK231234 .5, SIP/2 . 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl.homel.net;branch=z9hG4bK23273846 
Max-Forwards: 68 

Record-Route : <sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Contact : 
Content-Length : 



5. Evaluation of Initial Filter criteria 

S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 

6. REFER request (S-CSCF to P-CSCF) - see example in table A.4.3.1.4-6 

The S-CSCF remembers (from registration procedures) the contact address of UE#2 and determines the 
P-CSCF assigned for UE#2 and routes the message there. The S-CSCF adds itself to the Via and Record- 
Route headers. 

Table A.4.3.1.4-6: REFER request (S-CSCF to P-CSCF) 



REFER sip: [5555 : :eee: fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK234974 .3, SIP/2 . 0/UDP 
icscf2 .home2 .net ;branch=z9hG4bK231234 .5, SIP/2 . 0/UDP 
scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
mrfcl .homel .net ;branch=z9hG4bK23273846 

Max-Forwards: 67 

Record-Route : <sip : scscf 2 . home2 . net ; lr> , <sip : scscf 1 . homel . net ; lr> 

P-Asserted- Identity : 

P-Charging-Vector: #### 

Privacy: 

From: 

To: 

Call-ID: 

Cseq: 

Refer-To: 

Ref erred-By : 

Contact : 

P- Called- Party- ID : <sip :user2_publicl@home2 .net> 

Content-Length : 
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7. REFER request (P-CSCF to UE#2) - see example in table A.4.3.1.4-7 

The P-CSCF forwards the request to UE#2. 

Table A.4.3.1.4-7: REFER request (P-CSCF to UE#2) 



REFER sip: [5555 : :eee : fff :aaa:bbb] : 8805;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK249354 . 1 , SIP/2 . 0/UDP 

scscf2 .home2 .net ;branch=z9hG4bK234974 .3, SIP/2 .0/UDP 

icscf2.home2 .net ;branch=z9hG4bK231234 .5, SIP/2 . 0/UDP 

scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2 .0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Max- Forwards : 66 
Record- Route : <sip :pcscf 2 . visited2 .net : 5 088 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net ; lr>, 

<sip : scscf 1 . homel . net ; lr> 
P-Asserted- Identity : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Ref erred-By : 
Contact : 

P-Called-Party-ID: 
Content-Length: 



202 (Accepted) response (UE#2 to P-CSCF) - see example in table A.4.3.1.4-8 

UE# accepts the REFER request by sending a 202 (Accepted) response. 

Table A.4.3.1.4-8: 202 (Accepted) response (UE#2 to P-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 2 .visited2 . net : 5088 ; comp=sigcomp;branch=z9hG4bK249354 . 1 , SIP/2 . 0/UDP 

scscf 2 .home2 .net ;branch=z9hG4bK234974 .3, SIP/2 .0/UDP 

icscf2.home2 .net ;branch=z9hG4bK231234 .5, SIP/2 . 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip : pcscf 2 . visited2 .net : 50 8 8 ; lr;comp=sigcomp>, <sip:scscf2 .home2 .net; lr>, 

<sip : scscf 1 . homel . net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
Privacy : none 

From: <sip : conferencelOmrf cl . homel . net> ; tag=171828 
To : <sip : user2_publicl@home2 . net> ; tag=151170 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 127 REFER 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Content-Length : 
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9. 202 (Accepted) response (P-CSCF to S-CSCF) - see example in table A.4.3.1.4-9 

The P-CSCF forwards the response to the S-CSCF. 

Table A.4.3.1.4-9: 202 (Accepted) response (P-CSCF to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK234974 . 3 , SIP/2 . 0/UDP 

icscf2 .home2 .net ;branch=z9hG4bK231234 .5, SIP/2 .0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record- Route : <sip ipcscf 2 . visited2 .net;lr>, <sip:scscf2 .home2 .net ; lr>, 

<sip : scscf 1 . homel . net ; lr> 
P-Access-Network-Info : 

P-Asserted- Identity : <sip :user2_publicl@home2 .net> 
P-Charging-Vector: #### 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 



10. 202 (Accepted) response (S-CSCF to I-CSCF) - see example in table A.4.3.1.4-10 

The S-CSCF forwards the response to the I-CSCF. 

Table A.4.3.1.4-10: 202 (Accepted) response (S-CSCF to I-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP icscf2 .home2 .net;branch=z9hG4bK231234 .5, SIP/2. 0/UDP 

scscf l.homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK23273846 
Record-Route : 

P-Asserted-Identity: "John Smith" <sip :user2_publicl@home2 .net ; <tel : +l-212-555-2222> 
P-Charging-Vector: #### 
P-Charging-Function-Addresses : #### 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 



1 1. 202 (Accepted) response (I-CSCF to S-CSCF) - see example in table A.4.3.1.4-11 

The I-CSCF forwards the response to the S-CSCF. 

Table A.4.3.1 .4-1 1 : 202 (Accepted) response (I-CSCF to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf l.homel. net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 

mrfcl. homel. net ;branch=z9hG4bK23273846 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector : 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 
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12. 202 (Accepted) response (S-CSCF to MRFC/AS) - see example in table A.4.3.1.4-12 

The S-CSCF forwards the response to the MRFC/AS. 

Table A.4.3.1.4-12: 202 (Accepted) response (S-CSCF to MRFC/AS) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK23273846 

Record-Route : 

P-Asserted- Identity : 

P-Charging-Vector : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 



13. NOTIFY request (UE#2 to P-CSCF) - see example in table A.4.3.1.4-13 

According to RFC 3515 [17], UE#2 creates a subscription and sends a notification of the status of the refer. 

Table A.4.3.1.4-13: NOTIFY request (from UE#2 to P-CSCF) 



NOTIFY sip:conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

Max- Forwards : 70 

Route: <sip :pcscf 2 . visited2 .net:5088;lr>, <sip:scscf2 .home2 .net ; lr>, 

<sip : scscf 1 . homel . net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
To: <sip : conferencel@mrfcl .homel .net >;tag=171828 
From: <sip :user2_publicl@home2 . net >;tag=15 117 
Call-ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 42 NOTIFY 

Subscript ion- St ate : active /expires : 72 
Event : refer 
Contact : <sip:user2_publicl@home2 .net ;gr=urn:uuid: 2ad8950e-4 8a5-4a74-8d99-ad76cc7f c74 

;comp=sigcomp> 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 100 Trying 



14. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A.4.3.1.4-14 

The P-CSCF forwards the message to the S-CSCF. 

Table: A.4.3.1.4-14: NOTIFY request (from P-CSCF to S-CSCF) 



NOTIFY sip :conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK234223 . 1 , SIP/2. 0/UDP 

[5555 : :eee: f f f :aaa:bbb] : 8805 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max- Forwards : 69 

Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr> 
P-Access-Network-Inf o : 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type: 

(...) 
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15. NOTIFY request (from S-CSCF to S-CSCF - see example in table A.4.3.1.4-15 

The S-CSCF forwards the message to the S-CSCF. 

Table A.4.3.1.4-15: NOTIFY request (from S-CSCF to S-CSCF) 



NOTIFY sip:conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 2 . home2 . net ;branch=z9hG4bK7S4z87 . 1 , SIP/2. 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max- Forwards : 68 

Route : <sip : scscf 1 . homel . net ; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 



16. NOTIFY request (from S-CSCF to MRFC/AS- see example in table A.4.3.1.4-16 

The S-CSCF forwards the message to the MRFC/AS. 

Table A.4.3.1.4-16: NOTIFY request (from S-CSCF to MRFC/AS) 



NOTIFY sip :conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf 1. homel. net ;branch=z9hG4bK23436s.l, SIP/2. 0/UDP 
scscf 2 .home2 .net ;branch=z9hG4bK7S4z87 . 1, SIP/2 .0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 

Max- Forwards : 67 

To: 

From: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Contact : 

Content-Length: (...) 

Content-Type : 

(...) 



17. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.4.3.1.4-17 

The MRFC/AS acknowledges the NOTIFY request with a 200 (OK) response to the S-CSCF. 

Table A.4.3.1.4-17: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 












Via: SIP/2. 0/UDP scscf 1. homel 


net;branch=z9hG4bK23436s.l, SIP/2 


0/UDP 


scscf2 


home2 . net ; branch= 


=z9hG4bK764z87.1, 


SIP/2. 0/UDP 




pcscf 2 


visited2 


.net ;branch= 


=z9hG4bK234223 


1, SIP/2. 0/UDP 




[5555: 


eee : f f f : 


aaa :bbb] 


8805;Comp=sigcomp;branch=z9hG4bK23dh42 . 1 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 
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18. 200 (OK) response (S-CSCF to S-CSCF) - see example in table A.4.3.1.4-18 

The S-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.4-18: 200 (OK) response (S-CSCF to S-CSCF) 



SIP/2.0 200 OK 












Via: SIP/2. 0/UDP scscf2.home2 


net;branch=z9hG4bK7S4z 


87.1, SIP/2 


0/UDP 


pcscf2 .visited2 


.net ;branch= 


=z9hG4bK234223.1, 


SIP/2 


.0/UDP 




[5555: :eee:fff : 


aaa:bbb] : 8805 ;comp=sigcomp;b 


ranch= 


z9hG4bK23dh42.1 


From: 












To: 












Call-ID: 












CSeq: 












Content-Length: 













19. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.3.1.4-19 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.3.1.4-19: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 
Via: SIP/2. 0/UDP 
[5555: :eee:fff 


pcsc 
: aaa 


f2 .visited2 
:bbb] :8805; 


.net 
c:omp= 


branch= 
= sigcomp 


z9hG4bK234223.1, SIP/2. 
;branch=z9hG4bK23dh42 . 1 


0/UDP 


From: 




















To: 




















Call-ID: 




















CSeq: 

Content-Length: 





















20. 200 (OK) response (P-CSCF to UE#2) - see example in table A.4.3.1.4-20 

The P-CSCF forwards the 200 (OK) response to UE#2. 

Table A.4.3.1.4-20: 200 (OK) response (P-CSCF to UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



21. UE#2 joins the conference. 

UE#2 joins the conference as described in subclause 5.3.1.4. 
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22. NOTIFY request (UE#2 to P-CSCF) - see example in table A.4.3.1.4-22 

The P-CSCF receives a NOTIFY request from UE#2 indicating the status of the refer. 

Table A.4.3.1.4-22: NOTIFY request (from UE#2 to P-CSCF) 



NOTIFY sipiconferencelomrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

Max-Forwards: 70 

Route : <sip :pcscf 2 . visited2 .net:5088;lr>, <sip:scscf2 .home2 .net ; lr>, 

<sip : scscf 1 . homel . net ; lr> 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
To: <sip : conferencelomrfcl .homel .net >;tag=171828 
From: <sip :user2_publicl@home2 . net >;tag=15 117 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 42 NOTIFY 

Subscription-State: terminated 
Event : refer 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 200 OK 



23. NOTIFY request (from P-CSCF to S-CSCF) - see example in table A.4.3.1.4-23 

The P-CSCF forwards the message to the S-CSCF. 

Table: A.4.3.1.4-23: NOTIFY request (from P-CSCF to S-CSCF) 



NOTIFY sip :conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK234223 . 1 , SIP/2. 0/UDP 

[5 555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max- Forwards : 6 9 
P-Access-Network-Info : 

Route: <sip : scscf 2 .home2 .net ; lr>, <sip : scscf 1 .homel .net ; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



24. NOTIFY request (from S-CSCF to S-CSCF - see example in table A.4.3.1.4-24 

The S-CSCF forwards the message to the S-CSCF. 

Table A.4.3.1.4-24: NOTIFY request (from S-CSCF to S-CSCF) 



NOTIFY sip :conferencel@mrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscf2 .home2 .net;branch=z9hG4bK764z87.1, SIP/2 . 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555: :eee: f f f :aaa:bbb] : 88 05 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 
Max-Forwards: 68 

Route : <sip : scscf 1 . homel . net ; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



25. NOTIFY request (from S-CSCF to MRFC/AS- see example in table A.4.3.1.4-25 
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The S-CSCF forwards the message to the MRFC/AS. 

Table A.4.3.1.4-25: NOTIFY request (from S-CSCF to MRFC/AS) 



NOTIFY sipiconferencelOmrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl. homel. net;branch=z9hG4bK23436s.l, SIP/2. 0/UDP 
scscf2 .home2 .net ;branch=z9hG4bK764z87 . 1, SIP/2 . 0/UDP 
pcscf2 .visited2 .net ;branch=z9hG4bK234223 .1, SIP/2 . 0/UDP 
[5555 : :eee: f f f :aaa:bbb] : 8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 

Max- Forwards : 6 7 

To: 

From: 

Call-ID: 

CSeq: 

Subscription-State : 

Event : 

Content-Length: (...) 

Content-Type : 

(...) 



26. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.4.3.1.4-26 

The MRFC/AS acknowledges the NOTIFY request with a 200 (OK) response to the S-CSCF. 

Table A.4.3.1.4-26: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscfl . homel . net ;branch=z9hG4bK23436s . 1 , SIP/2 
scscf2 .home2 .net;branch=z9hG4bK764z87 .1, SIP/2 . 0/UDP 


0/UDP 


pcscf2 .visited2 


.net ;branch= 


=z9hG4bK234223 


1, SIP/2. 0/UDP 




[5555: :eee:fff : 


aaa :bbb] 


8805;comp=sigcomp;branch=z9hG4bK23dh42 . 1 


From: 












To: 












Call-ID: 












CSeq: 
Content-Length: 













27. 200 (OK) response (S-CSCF to S-CSCF) - see example in table A.4.3.1.4-27 

The S-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.3.1.4-27: 200 (OK) response (S-CSCF to S-CSCF) 



SIP/2.0 200 OK 














Via: SIP/2. 0/UDP scscf2.home2 


net;branch=z9hG4bK764z 


87.1, SIP/2 


0/UDP 


pcscf2 .visited2 


.net ;branch= 


=z9hG4bK234223.1, 


SIP/2 


.0/UDP 




[5555: :eee:fff : 


aaa :bbb] 


: 88 05 ;comp=sigcomp;b 


ranch= 


z9hG4bK23dh42.1 


From: 














To: 














Call-ID: 














CSeq: 














Content-Length: 















28. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.4.3.1.4-28 

The S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.4.3.1.4-28: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 


Via: SIP/2. 0/UDP pcscf 2 . visited2 . net ;branch=z9hG4bK234223 . 1 , SIP/2. 0/UDP 


[5555 : :eee: f f f :aaa:bbb] : 88 05 ;comp=sigcomp;branch=z9hG4bK23dh42 . 1 


From: 


To: 


Call-ID: 


CSeq: 


Content-Length: 
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29. 200 (OK) response (P-CSCF to UE#2) - see example in table A.4.3.1.4-29 

The P-CSCF forwards the 200 (OK) response to UE#2. 

Table A.4.3.1.4-29: 200 (OK) response (P-CSCF to UE#2) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :eee:fff :aaa:bbb] : 8805 ; comp=sigcomp;branch=z9hG4bK23dh42 . 1 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



A.4.4 User requesting IMS to join another user 
A.4.4.1 IVIRFC/AS is locatecJ in user's inome network 

Figure A.4.4. 1-1 shows how UE#1 invites UE#2 to a conference by sending a REFER request to MRFC/AS. UE#1 has 
created a conference by using the mechanisms described in subclause 5.3.1.3, and UE#1 has learned the conference URI 
that identifies this conference. 
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Visited Networl< 



UE#1 Home Networl< 



UE#1 



P-CSCF#1 



S-CSCF#1 



IVI RFC/AS 



1 . UE#1 creates a conference 



-9. 202Accepted- 



< — 12. NOTIFY - 



-2. REFER > 



-13. 200 OK > 



-19. NOTIFY- 



-20. 200 OK > 



-3. REFER ► 



4. Evaluation of initial 
Filter Criteria 



-8. 202Accepted- 



< — 1 1. NOTIFY - 



-14. 200 OK ► 



< — 18. NOTIFY - 



-21. 200 OK > 



-5. REFER ► 



-6. 202 Accepted - 



7. Invite user to 
conference. 



■10. NOTIFY - 



-15. 200 OK — ► 



16. Referred user joins 
the conference. 



< — 17. NOTIFY - 



-22. 200 OK ► 



Figure A.4.4.1-1 : User inviting anothier user to a conference by 
sending a REFER request to IVIRFC/AS 

The details of the flows are as follows: 

1 . UE#1 creates a conference 

UE#1 creates a conference as described in subclause 5.3.1.3. Once the conference creation is accomplished, 
UE#1 has learned the conference URI allocated for this conference. 
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2. REFER request (UE to P-CSCF) - see example in table A.4.4.1-2 

A UE has created a conference and learned the conference URL Now the UE wants to join another UE to that 
conference. 

Table A.4.4.1-2: REFER request (UE to P-CSCF) 



REFER sip: conferencel@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171828 

To: <sip: conferencelOmrfcl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 REFER 

Require: sec -agree 

Refer-To : <sip : user2_publicl@home2 . net ;method=INVITE> 

Proxy-Require: sec-agree 

Supported: gruu 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Content-Length: 



Request-URI: contains the conference URI as learned during the conference establishment. 
3. REFER request (P-CSCF to S-CSCF) - see example in table A.4.4.1-3 

The REFER request is forwarded to the S-CSCF. 

Table A.4.4.1-3: REFER request (P-CSCF to S-CSCF) 



REFER sip: conferencel@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34 .1, SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 69 

Route : <sip : orig@scscf 1 . homel . net ; lr> 
Record- Route : <sip : pcscf 1 .visitedl .net; lr> 

P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net> 
P-Charging-Vector: #### 
P-Access-Network-Info : 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Supported: 
Contact : 
Content-Length : 



4. Evaluation of initial Filter Criteria 

The S-CSCF validates the service profile of this subscriber and evaluates the initial filter criteria. 
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5. REFER request (S-CSCF to MRFC/AS) - see example in table A.4.4.1-5 

The S-CSCF forwards the REFER request to the address obtained by a DNS query. The S-CSCF adds itself 
to the Record-Route header. 

Table A.4.4.1-5: REFER request (S-CSCF to MRFC/AS) 



REFER sip:user2_publicl@home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max- Forwards : 68 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip ipcscf 1 . visitedl .net ; lr> 
P-Asserted-Identity : "John Doe" <sip :userl_publicl@homel .net>, <tel : +358-50-4821437> 
P-Charging-Vector: #### 
Privacy: 
From: 
To: 

Call-ID: 
Cseq: 
Refer-To: 
Supported: 
Contact : 
Content-Length : 



6. 202 (Accepted) response (MRFC/AS to S-CSCF) - see example in table A.4.4.1-6 

The MRFC/AS indicates that it has received the REFER request by sending a 202 (Accepted) response. This 
means that MRFC/AS has accepted the REFER request and has begun to process the request. This does not 
mean, however, that the referred-to resource would have been contacted. 

Table A.4.4.1-6: 202 (Accepted) response (MRFC/AS to S-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK332b23 .1, SIP/2. 0/UDP 
pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 
[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record- Route : <sip:scscfl .homel .net; lr>, <sip: pcscfl .visitedl .net ; lr> 
P-Asserted- Identity : <conf erencelOmrf cl .homel .net> 
P-Charging-Vector: #### 
Privacy : none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 
To : <sip : conf erencelomrf cl .homel .net>; tag=151170 
Call -ID: Cb03a0s0 9a2sdfglkj 490333 
CSeq: 127 REFER 

Contact : <sip : conf erencelomrf cl . homel . net> ; isf ocus 
Content-Length : 



Contact: contains the conference URI for the conference allocated at the MRFC/AS and the "isfocus" 

feature parameter. 

7. INVITE request user to conference 

The MRFC/AS invites the user, who is indicated in the Refer-To header of the received REFER request. It 
does apply the procedures as shown in subclause A.4.3.1.3. 
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8. 202 (Accepted) response (S-CSCF to P-CSCF) - see example in table A.4.4.1-8 

The S-CSCF forwards the response to the P-CSCF. 

Table A.4.4.1-8: 202 (Accepted) response (S-CSCF to P-CSCF) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP pcscf 1 . visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKjiashds7 
Record-Route : 
P-Asserted- Identity : 
P-Charging-Vector: #### 
Privacy: 
From: 
To: 

Call-ID: 
CSeq: 
Contact : 
Content-Length : 



202 (Accepted) response (P-CSCF to UE#1) - see example in table A.4.4.1-9 

The P-CSCF forwards the response to UE#1. 

Table A.4.4.1-9: 202 (Accepted) response (P-CSCF to UE#1) 



SIP/2.0 202 Accepted 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route : 

P-Asserted- Identity : 

Privacy: 

From: 

To: 

Call-ID: 

CSeq: 

Contact : 

Content-Length : 



10. NOTIFY request (MRFC/AS to S-CSCF) - see example in table A.4.4.1-10 

The MRFC/AS sends a NOTIFY request to inform the S-CSCF about the progress of the REFER request 
processing. The body of the NOTIFY request contains a fragment of the response as received by the 
notifying UE for the request that was initiated due to the REFER request. 

Table A.4.4.1-10: NOTIFY request (from MRFC/AS to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP mrf c . homel . net ;branch=z9hG4bK23273846 
Max- Forwards : 70 

Route : <sip:scscfl .homel .net; lr>, <sip:pcscfl .visitedl .net ; lr> 
To : <sip :userl_publicl@homel .net>; tag=17182 8 
From: <sip : conf erencelOmrf cl .homel . net >;tag=15 1170 
Call -ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 42 NOTIFY 

Subscript ion- St ate : active /expires : 72 
Event: refer 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 100 Trying 
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1 1. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A.4.4.1-11 

The S-CSCF forwards the message to the P-CSCF. 

Table: A.4.4.1-1 1 : NOTIFY request (from S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK23436s . 1, SIP/2. 0/UDP 

mrfc.homel .net;branch= z9hG4bK23273846 
Max- Forwards : 69 

Route : <sip :pcscf 1 . visitedl .net; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 



12. NOTIFY request (from P-CSCF to UE#1) - see example in table A.4.4.1-12 

The P-CSCF forwards the message to UE#1. 

Table A.4.4.1-12: NOTIFY request (from P-CSCF to UE#1) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl . net : 7531 ; comp=sigcomp;branch=z9hG4bK23433 . 1 , SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK23436s.l, SIP/2 .0/UDP 

mrfc.homel .net ;branch=z9hG4bK2 3 2 73 84 6 
Max-Forwards: 68 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 

Content-Length: (...) 
Content-Type : 

(...) 



13. 200 (OK) response (UE to P-CSCF) - see example in table A.4.4.1-13 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.4.4.1-13: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .visitedl . net : 7531 ; comp=sigcomp;branch=z9hG4bK23433 . 1 , SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK23436s.l, SIP/2 .0/UDP mrfc .homel .net ;branch=z9hG4bK23273846 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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14. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.4.1-14 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.4.1-14: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK23436s . 1, 


SIP/2. 0/UDP 


mrfc.homel.net;branch=z9hG4bK23273846 




P-Access-Network-Info : 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





15. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.4.4.1-15 

The S-CSCF forwards the 200 (OK) response to MRFC/AS. 

Table A.4.4.1-15: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrfc. homel. net ;branch=z9hG4bK23273846 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length: 



16. Referred user joins the conference. 

The referred user joins the conference as described in subclause 5.3.1.4. 

17. NOTIFY request (from MRFC/AS to S-CSCF) - see example in table A.4.4.1-17 

The MRFC/AS sends a NOTIFY request that indicates that the referred party has joined the conference. 

Table A.4.4.1-17: NOTIFY request (from MRFC/AS to S-CSCF) 



NOTIFY sip: user l_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp SIP/2.0 
Via: SIP/2. 0/UDP mrf c . homel . net ;branch= z9hG4bK23273846 
Max-Forwards: 70 

Route : <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 . visitedl .net ; lr> 
To: <sip :Userl_publicl@homel .net>; tag=171828 
From: <sip : conf erencelOmrf cl .homel . net >;tag=15 117 
Call- ID: Cb03a0s09a2sdfglkj 490333 
CSeq: 43 NOTIFY 

Subscription-State: terminated 
Event : refer 
Content-Length: (...) 
Content-Type: message/sipf rag 

SIP/2.0 200 OK 



Subscription-State: indicates that the implicit subscription to the refer event has been terminated. 
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18. NOTIFY request (from S-CSCF to P-CSCF) - see example in table A.4.4.1-18 

The S-CSCF forwards the message to the P-CSCF. 

Table 6.3.3.1.1-18: NOTIFY request (from S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK23436s . 1, SIP/2. 0/UDP 

mrfc.homel .net;branch= z9hG4bK23273846 
Max- Forwards : 69 

Route : <sip :pcscf 1 . visitedl .net; lr> 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



19. NOTIFY request (from P-CSCF to UE#1) - see example in table A.4.4.1-19 

The P-CSCF forwards the message to UE#1. 

Table A.4.4.1-19: NOTIFY request (from P-CSCF to UE#1) 



NOTIFY sip: [5555 :: aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl .net : 7531;comp=sigcomp;branch=z9hG4bK23433 . 1, SIP/2. 0/UDP 

scscf 1 .homel .net;branch=z9hG4bK23436s .1, SIP/2 . 0/UDP 

mrfc.homel .net ;branch=z9hG4bK23273846 
Max-Forwards: 68 
To: 
From: 
Call-ID: 
CSeq: 

Subscription-State : 
Event : 

Content-Length: (...) 
Content-Type : 

(...) 



20. 200 (OK) response (UE to P-CSCF) - see example in table A.4.4.1-20 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.4.4.1-20: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl.visitedl.net :7531;comp=sigcomp;branch=z9hG4bK23433 .1, SIP/2. 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK23436s.l, SIP/2 .0/UDP mrfc .homel .net ;branch=z9hG4bK23273846 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length: 
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21. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.4.4.1-21 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.4.4.1-21 : 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK23436s . 1, 


SIP/2. 0/UDP 


mrfc.homel.net;branch=z9hG4bK23273846 




P-Access-Network-Info : 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





22. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.4.4.1-22 

The S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.4.4.1-22: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrfc. homel. net ;branch=z9hG4bK23273846 

From: 

To: 

Call-ID: 

CSeq: 

Content-Length : 



A.4.5 User joins a private conversation to a conference 



A.4.5.1 User in a (different network 

Void 



A. 5 Flows demonstrating a user subscribing to the 
conference event package 

A. 5.1 Introduction 

Void 
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A. 5. 2 User subscribing to the conference event package 
A.5.2.1 IVIRFC/AS is not located in user's iiome network 



Visited Networl< 



UE#1 Home 
Networl< 



IVIRFC/AS Home 
Network 









UE#1 




P-CSCF 



-1.SUBSCRIBE- 



•< 7. 200 OK- 



-10. NOT! FY - 



-11. 200 OK ► 



S-CSCF 



-2. SUBSCRIBE- 



MRFC/AS 



3. Evaluation of initial 
Filter Criteria 



— 4. SUBSCRIBE- 



< 6. 200 OK- 



< 9. NOTIFY - 



-12. 200 OK ► 



< 5. 200 OK- 



< 8. NOTIFY - 



■13. 200 OK ► 



Figure A.5.2.1-1 : User subscribing to conference event package - 
IVIRFC/AS is not located in user's home network 

Figure A.5.2.1-1 shows an user subscribing to the conference state event for a specific conference that is provided at a 
MRFC/AS located in another network. The conference URI, which is used for subscription to the conference event 
package, does include a FQDN in the host part in this example. 

The details of the flows are as follows: 

1. SUBSCRIBE request (UE to P-CSCF) - see example in table A.5.2.1-1 

A UE wants to get informed about the state of a certain conference, the involved users and their related media 
states. The conference is identified by a conference URL In order to initiate a subscription to the MRFC/AS, 
the UE generates a SUBSCRIBE request containing the 'conference' event, together with the length of time 
this periodic subscription should last. 
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Table A.5.2.1-1 : SUBSCRIBE request (UE to P-CSCF) 



SUBSCRIBE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 70 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip lorigOscscf 1 .homel .net; lr> 

P -Preferred- Identity : <sip :userl_publicl@homel .net> 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=31415 

To : <sip : conf erencelOmrf c2 . home2 . net> 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 61 SUBSCRIBE 

Require: sec-agree 

Proxy-Require: sec-agreeSecurity-Verify : ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; 

spi-s=87654321; port-c=8642; port-s=7531 

Event : conference 

Expires: 7200 

Accept : application/conf erence-inf o+xml 

Contact: <sip: [5555 :: aaa :bbb : ccc :ddd] : 1357;comp=sigcomp> 

Content-Length: 



Request-URI: contains the conference URL 

2. SUBSCRIBE request (P-CSCF to S-CSCF) - see example in table A.5.2.1-2 

The SUBSCRIBE request is forwarded to the S-CSCF. 

Table A.5.2.1-2: SUBSCRIBE request (P-CSCF to S-CSCF) 



SUBSCRIBE sip : conf erencelOmrf c2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP pcscfl .visitedl .net ;branch=z9hG4bK240f 34 . 1, SIP/2. 0/UDP 

[5555 : :aaa :bbb: ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
P-Access-Network-Info : 
Max-Forwards: 69 

P-Asserted- Identity : <sip :userl_publicl@homel .net> 

P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" 
Privacy: 

Route : <sip : origOscscf 1 . homel . net ; lr> 
Record- Route : <sip : pcscfl .visitedl .net ; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Event : 

Expires : Accept : 
Contact : 
Content-Length : 



3. Evaluation of initial filter criteria 

The S-CSCF vaHdates the service profile of this subscriber and evaluates the initial filter criteria. 
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4. SUBSCRIBE request (S-CSCF to MRFC/AS) - see example in table A.5.2.1-4 

S-CSCF forwards the SUBSCRIBE request to the MRFC/AS based on the Request URI of the SUBSCRIBE 
request. The S-CSCF does not re-write the Request URI. 

Table A.5.2.1-4: SUBSCRIBE request (S-CSCF to MRFC/AS) 



SUBSCRIBE sip:conferencel@mrfc2 .home2 .net SIP/2.0 

Via: SIP/2. 0/UDP scscfl.homel.net;branch=z9hG4bK351g45.1, SIP/2 . 0/UDP 
pcscfl.visitedl.net;branch=z9hG4bK24 0f34 .1, SIP/2 .0/UDP 
[5555 : : aaa :bbb : ccc : ddd] : 13 57 ; comp=sigcomp;branch=z9hG4bKnashds7 
Max-Forwards: 67 
P-Asserted- Identity : 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 
Privacy: 

Record- Route : <sip:scscfl .homel .net ; lr>, <sip :pcscf 1 . visitedl; lr> 
From: 
To: 

Call-ID: 
CSeq: 
Event : 

Expires : Accept : 
Contact : 
Content-Length : 



5. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.5.2.1-5 (related to table A,5.2,l-4) 

The MRFC/AS performs the necessary authorization checks on the originator to ensure that he/she is allowed 
to subscribe to this specific conference. In this example the conditions have been met, so the MRFC/AS 
acknowledges the SUBSCRIBE request (6) with a 200 (OK) response. 

Table A.5.2.1-5: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1. homel. net;branch=z9hG4bK351g45 .1, SIP/2 . 0/UDP 

pcscfl .visitedl .net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 
P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net; 

term-ioi=home2 .net 
From: 

To : <sip : conf erencelOmrf c2 . home2 . net> ; tag=151170 
Call-ID: 
CSeq: 
Event : 
Expires : 

Contact : <sip : conf erencelOmrf c2 . home2 . net> 
Content-Length : 



6. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.5.2.1-6 

S-CSCF forwards the 200 (OK) response to the P-CSCF. 

Table A.5.2.1-6: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , SIP/2. 0/UDP 

[5555 : : aaa :bbb : ccc :ddd] : 13 57;comp=sigcomp;branch=z9hG4bKnashds7 
Record-Route : 

P- Charging- Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" 
From: 
To: 

Call-ID: 
CSeq: 
Event : 
Expires : 
Contact : 
Content-Length : 
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7. 200 (OK) response (P-CSCF to UE) - see example in table A.5.2.1-7 

The P-CSCF forwards the 200 (OK) response to the UE. 

Table A.5.2.1-7: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Record-Route : 

From: 

To: 

Call-ID: 

CSeq: 

Event : 

Expires : 

Contact : 

Content-Length : 



8. NOTIFY request (MRFC/AS to S-CSCF) - see example in table A.5.2.1-8 

The MRFC/AS generates a NOTIFY request that includes information about all participants that the 
subscribing user is allowed to see. The information about one participant includes: 

the SIP URI identifying the user; 

the dialog state associated for that users attachment to the conference; and 

the users status in terms of media in the conference. 
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Table A.5.2.1-8: NOTIFY request (MRFC/AS to S-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357; comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP mrf c2 . home2 . net ;branch=z9hG4bK348923 . 1 

Max- Forwards : 70 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=123551024" ; orig-ioi=homel .net 

Route : <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net; lr> 

From: <sip : conf erencelomrf c2 .home2 .net>; tag=151170 

To : <sip : userl_publicl@homel . net> ; tag=31415 

Call -ID: b8 9rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: active ;expires=7200 

Event: conference ;recurse 

Contact : <sip : conf erencelomrf c2 . home2 . net> 

Content-Type : application/conf erence-info+xml 

Content-Length: (...) 

<?xml version="l . 0" encoding="UTF-8" ?> 

< conf erence- info xmlns="urn: ietf :params :xml :ns : conf erence- info" > 
ent ity=" conf erencelomrf c2 .homel .net" 
state="full" 
version="0" 
<user entity="sip :userl_publicl@homel .net" > 
<display- text>John Doe</display-text> 
<endpoint entity=" sip : [5555 :: eee : fff : aaa :bbb] " > 
< status >connected</ status > 

< joining-method>dialed-in</ joining-method> 
<media id="l"> 
< type >audio</ type > 
< label >34 56 7< /label > 
<src-id>534232</src-id> 
< status >sendrecv< /status > 
</media> 
</endpoint> 
<user entity="sip :user3_publicl@home3 .net" > 
<display- text>Simon Moon</display-text> 
<endpoint entity=" sip : [5555 :: eee : fff : aaa :bbb] " > 
< status >on-hold</ status > 

< joining-method>dialed-in</ joining-method> 
<media id="l"> 
< type >audio</ type > 
< label >34 56 7</ label > 
<src-id>534232</src-id> 
< status >sendrecv< /status > 
</media> 
</endpoint> 
</user> 
</ conf erence -info > 



P-Charging- Vector: The MRFC/AS populates the icid parameter with a globally unique value and populates the 
identifier of its own network to the terminating Inter Operator Identifier (lOI) parameter of 
this header. 

The message body in the NOTIFY request that carries the conference state information of the conference 
participants is formed as indicated in RFC 4575 [11]. 

9. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.5.2.1-9 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 
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Table A.5.2.1-9: NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357; comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

mrfc2 .home2 .net ;branch=z9hG4bK348923 . 1 
Max-Forwards: 69 

P- Charging- Vector: icid-value="AyretyUOdm+602IrT5tAFrbHLso=123 551024" 
P- Charging- Function-Addresses : ccf = [5555 : :b99 : c8 8 :d77 : e6 6] ; ccf = [5555 : : a55 :b44 : c33 :d22] 

ecf= [5555: : If f : 2ee : 3dd: 4cc] ; ecf= [5555 : : 6aa : 7bb : Sec : 9dd] 
Route : <sip :pcscf 1 . visitedl .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content-Type : 
Content-Length : 

(...) 



10. NOTIFY request (P-CSCF to UE) - see example in table A.5.2.1-10 

The P-CSCF forwards the NOTIFY request to the UE. 

Table A.5.2.1-10: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34 .1, SIP/2. 0/UPD 

scscf 1. homel. net ;branch=z9hG4bK332b23.1, SIP/2 .0/UDP mrfc2 .home2 .net ;branch=z9hG4bK348923 .1 
Max- Forwards : 6 8 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content-Type : 
Content-Length : 

(...) 



1 1. 200 (OK) response (UE to P-CSCF) - see example in table A.5.2,1-11 (related to table A,5.2.1-10) 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.5.2.1-11 : 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 




















Via: SIP/2. 0/UDP 


pcscf 1 .visitedl . 


net ;branch= 


=z9hG4bK240f34 


1, SIP/2. 


0/UPD 




scscf 1 . homel . net 


branch=z9hG4bK332b23.1, 


SIP/2 


0/UDP mrfc2.home2 


.net ;branch= 


z9hG4bK348923.1 


P -Access -Network 


-Info: 3GPP 


-UTRAN 


-TDD; utran-cell 


-id-3gpp= 


=234151D0FCE11 




From: 




















To: 




















Call-ID: 




















CSeq: 




















Content-Length: 
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12. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.5.2.1-12 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.5.2.1-12: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UPD scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfc2 .home2 .net ;branch=z9hG4bK348923 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=123551024" 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 



13. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.5.2.1-13 

The S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.5.2.1-13: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 




Via: SIP/2. 0/UDP mrfc2.home2.net;branch=z9hG4bK348923.1 




P- Charging- Vector: icid-value= "AyretyU0dm+6O2IrT5tAFrbHLso=123 551024 " ; 


orig- ioi=homel . net ; 


term-ioi=homel .net 




From: 




To: 




Call-ID: 




CSeq: 




Content-Length: 





A. 6 Flows demonstrating a user leaving a conference 
A. 6.1 Introduction 

Void 

A. 6. 2 User leaving the conference 

A.6.2.1 MRFC/AS is located in user's inome network 

Figure A. 6. 2. 1-1 shows an user leaving a conference. The example shows the flow for the user, who created the 
conference with a conference-factory URL For this example it is assume that the user is subscribed to the conference 
state event package at the MRFC/AS. 
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Visited networl< 



UE#1 Home networl< 



UE#1 



P-CSCF 



-1. BYE ► 



S-CSCF 



2. Remove 

resource 

reservation 



< 8. 200OK- 



< — 12. NOTIFY - 



-13. 200 OK ► 



-3. BYE- 



-7. 200 OK- 



-11. NOTIFY - 



-14. 200 OK ► 



IVIRFC/AS 



-4. BYE- 



IVIRFP 



5. H.248 interaction to 
release connection 
resources for UE#1 



< 6. 200OK- 



-9. NOTIFY - 



10. NOTIFY toother 
conference 
participants 



-15. 200 OK > 



Figure A.6.2.1-1 : User leaving a conference 

The details of the flows are as follows. 

1. BYE (UE to P-CSCF) - see example in table A.6.2.1-1 

A UE wants to leave a conference. For this purpose the UE sends a BYE message to the P-CSCF with the 
Conference-URI as the Request-URL 

Table A.6.2.1-1 : BYE (UE to P-CSCF) 



BYE sip : conf erencelOmrf cl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa : bbb : ccc : ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : < sip :pcscfl .visitedl .net : 75 31; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net ; lr> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

From: <sip :userl_publicl®homel .net>; tag=171828 

To: <sip : conference-factorylomrfcl .homel .net>; tag=314159 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Require: sec-agree 

Proxy-Require: sec-agree 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=987S5432 ; spi-s=87654321; 

port-c=8S42; port-s=7531 
Cseq: 153 BYE 
Content-Length: 



Request-URI: contains the value of the Conference-URI as learned during conference creation. 

2. Remove resource reservation 

The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for 
this session. This step will also result in a release indication to the GPRS subsystem to confirm that the IP 
bearers associated with the session have been deleted. 
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3. BYE (P-CSCF to S-CSCF) - see example in table A.6.2.1-3 

The P-CSCF removes the Security- Verify header, and the "sec-agree" option tag from the Require and 
Proxy-Require headers. As the Require and Proxy-Require headers are empty, it removes these headers 
completely. 

Table A.6.2.1-3: BYE (P-CSCF to S-CSCF) 



BYE sip :conferencel@mrfcl .homel.net SIP/2.0 


Via: SIP/2. 0/UDP pcscfl.visitedl.net;branch=z9hG4bK240f34.1, SIP/2 . 0/UDP 


[5555 : : aaa :bbb : ccc : ddd] : 13 5 7 ; comp=sigcomp;branch=z9hG4bKnashds7 


Max- Forwards : 69 


Route : <sip :orig@scscf 1 .homel .net; lr> 


P-Access-Network-Info : 


From: 


To: 


Call-ID: 


Cseq: 


Content-Length: 



4. BYE (S-CSCF to MRFC/AS) - see example in table A.6.2.1-4 

The S-CSCF forwards the BYE to the MRFC/AS. 

Table A.6.2.1-4: BYE (S-CSCF to MFRC/AS) 



BYE sip:conf erencelOmrf cl . 


homel 


.net SIP/2.0 








Via: SIP/2. 0/UDP scscfl. homel. net ;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . visitedl .net ;branch=z 


3hG4bK240f34.1, 


SIP/2 


.0/UDP 




[5555: :aaa:bbb:ccc:ddd] 


:1357 


- comp= s igcomp ; b 


ranch= 


z9hG4bKnashds7 


P-Access-Network-Inf o : 












Max-Forwards: 68 












From: 












To: 












Call-ID: 












Cseq: 












Content-Length: 













5. H.248 interaction to release resources 

The MRFC/AS interacts with the MRFP to release the resources reserved for UE#1 in this conference. 

6. 200 (OK) response (MRFC/AS to S-CSCF) - see example in table A.6.2.1-6 

After successfully releasing the resources from the MRFP, the MRFC/AS sends a 200 (OK) response request 
to the S-CSCF. 

Table A.6.2.1-6: 200 (OK) response (MRFC/AS to S-CSCF) 



SIP/2.0 200 OK 












Via: SIP/2 


.0/UDP scscfl. homel 


net;branch=z9hG4bK332b23.1, SIP/2 


0/UDP 


pcscf 1 . 


visitedl 


.net ;branch= 


=z9hG4bK240f34.1, 


SIP/2 


0/UDP 




[5555: : 


aaa :bbb : 


ccc:ddd] : 1357;comp=sigcomp;b 


ranch= 


29hG4bKnashds7 


From: 














To: 














Call-ID: 














Cseq: 














Content-Le 


ngth: 













7. 200 (OK) response (S-CSCF to P-CSCF) - see example in table A.6.2.1-7 

S-CSCF forwards the 200 (OK) response to the P-CSCF. 
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Table A.6.2.1-7: 200 (OK) response (S-CSCF to P-CSCF) 



SIP/2.0 200 OK 




















Via: SIP/2. 0/UDP 


pcsc 


f 1 .visitedl 


.net 


branch= 


z9hG4bK240f34 


1, 


SIP/2 


0/UDP 


[5555: :aaa:bbb 


: ccc 


:ddd] 


:1357; 


::omp= 


=sigcomp 


;branch=z9hG4bKnashds7 




From: 




















To: 




















Call-ID: 




















Cseq: 




















Content-Length: 





















200 (OK) response (P-CSCF to UE) - see example in table A,6.2.1-8 

P-CSCF forwards the message to the UE. 

Table A.6.2.1-8: 200 (OK) response (P-CSCF to UE) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc:ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

From: 

To: 

Call-ID: 

Cseq: 

Content-Length : 
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9. NOTIFY request (MRFC/AS to S-CSCF) - see example in table A.6.2.1-9 

The MRFC/AS generates a NOTIFY request to indicate that UE#1 has left the conference and automatically 
unsubscribe UE#1 from its subscription to the conference event package. 

Table A.6.2.1-9: NOTIFY request (MRFC/AS to S-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP mrfcl.homel.net;branch=z9hG4bK348923 .1 

Max- Forwards : 70 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=homel .net 

Route: <sip:scscfl .homel .net; lr>, <sip :pcscf 1 . visitedl .net; lr> 

From: <sip : conf erencel@mrf cl .homel . net >;tag=15 1170 

To : <sip :userl_publicl@homel .net>; tag=31415 

Call -ID: b89rjhnedlrf jflslj4 0a222 

CSeq: 42 NOTIFY 

Subscription-State: terminated 

Event : conference 

Contact : <sip : conf erencelOmrf cl . homel . net> 

Content-Type : application/conf erence-inf o+xml 

Content-Length: (...) 

<?xml version="l . 0" encoding="UTF-8" ?> 

<conf erence-inf o xmlns="urn: ietf :params :xml :ns : conf erence-inf o" > 
entity="conf erencel@mrf cl .homel .net" 
state="full" 
version="l" 
<user entity="sip :userl_publicl@homel .net" > 
<display- text>John Doe</display-text> 
<endpoint entity="sip: [5555: : aaa :bbb : ccc :ddd] "> 
< status >disconnected< /status > 

<disconnection-method>departed</disconnection-method> 
</endpoint> 
</user> 

<user entity="sip :user3_publicl@home3 .net" > 
<display- text>Simon Moon</display-text> 
<endpoint entity=" sip : [5555 :: eee : fff : aaa :bbb] " > 
< status >connected< /status > 

<joining-method>dialed-in</ joining-method> 
<media id="l"> 
< type >audio</ type > 
<label>34 5 6 7</label> 
<src-id>5342 82</src-id> 
< status >inactive< /status > 
</media> 
</endpoint> 
</user> 
</ conference -info 



P-Charging- Vector: The MRFC/AS populates the icid parameter with a globally unique value and 

populates the identifier of its own network to the originating Inter Operator 
Identifier (lOI) parameter of this header. 

P-Charging-Function-Addresses: The MRFC/AS populates the P-Charging-Function-Addresses header field to 

be passed to the S-CSCF. 

Subscription-State: Value of "terminated" indicates that the UE has been unsubscribed from the 

conference event package. 

The message body in the NOTIFY request that carries the conference state information of the conference 
participants is formed as indicated in RFC 4575 [11]. 

10. Other conference participants are notified 

MRFC/AS similarly notifies other conference participants that have subscribed to the conference event 
package that UE#1 has left the conference. 
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1 1. NOTIFY request (S-CSCF to P-CSCF) - see example in table A.6.2.1-11 

The S-CSCF forwards the NOTIFY request to the P-CSCF. 

Table A.6.2.1-11 : NOTIFY request (S-CSCF to P-CSCF) 



NOTIFY sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK348923 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" 
P- Charging- Function-Addresses : ccf= [5555: :b99:c88:d77:e66] ; ccf=[5555: :a55:b44:c33:d22] 

ecf= [5555 : :lff :2ee:3dd:4cc] ; ecf= [5555 : : 6aa : 7bb : Bcc : 9dd] 
Max- Forwards : 69 

Route : <sip :pcscf 1 . visitedl .net; lr> 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content-Type : 
Content-Length : 

(...) 



12. NOTIFY request (P-CSCF to UE) - see example in table A.6.2.1-12 

The P-CSCF forwards the NOTIFY request to the UE. 

Table A.6.2.1-12: NOTIFY request (P-CSCF to UE) 



NOTIFY sip: [5555 : :aaa:bbb:CCC:ddd] : 1357;comp = sigcomp SIP/2.0 

Via: SIP/2. 0/UDP pcscfl.visitedl.net :7531;comp=sigcomp;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UPD 

scscf 1 .homel .net, -branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP mrfcl .homel .net ;branch=z9hG4bK348923 . 1 
Max-Forwards: 68 
From: 
To: 

Call-ID: 
CSeq: 

Subscription-State : 
Event : 
Contact : 
Content-Type : 
Content-Length : 

(...) 



13. 200 (OK) response (UE to P-CSCF) - see example in table A.6.2.1-13 (related to table A.6.2.1-12) 

The UE acknowledges the NOTIFY request with a 200 (OK) response to the P-CSCF. 

Table A.6.2.1-13: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 
























Via: SIP/2. 0/UDP 


pcscf 1 .visitedl . 


net : 7531; 


comp=sigcomp;branch= 


=z9hG4bK240f34 


1, 


SIP/2 


0/UPD 


scscf 1 .homel . 


let 


branch= 


z9hG4bK332b23 .1 


, SIP/2 


0/UDP mrfcl 


homel .net 


branch: 


=z9hG4bK348923.1 


P- Access -Network 


-Info: 3GPP 


-UTRAN 


-TDD; utran-cell 


-id-3gpp=2 34151D0FCEll 










From: 
























To: 
























Call-ID: 
























CSeq: 
























Content-Length: 


























£75/ 



3GPP TS 24.1 47 version 1 0.2.0 Release 10 1 98 ETSI TS 1 24 1 47 VI 0.2.0 (201 2-01 ) 

14. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.2.1-14 

The P-CSCF forwards the 200 (OK) response to the S-CSCF. 

Table A.6.2.1-14: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UPD scscf 1 .homel .net ;branch=z9hG4bK332b23 . 1, SIP/2. 0/UDP 

mrfcl.homel .net ;branch=z9hG4bK348923 . 1 
P- Charging- Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 



15. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.6.2.1-15 

The S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.6.2.1-15: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP mrf cl. homel. net , -branch=z9hG4bK348923 .1 

P-Charging-Vector : icid-value="AyretyU0dm+6O2IrT5tAFrbHLso=223551024" ; orig-ioi=homel .net; 

term- ioi=homel . net 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
CSeq: 
Content-Length : 



A. 6. 3 User requesting to remove another user from conference 

The call flows for a user requesting the removal of another user from a conference are basically identical to the call 
flows for a user requesting IMS to join another user (see subclause A.4.4). The call flows only differ in the Refer-To 
header of the REFER request, namely in the 'method" parameter which is set to 'BYE" instead of 'INVITE" and the 
tasks performed by the MRFC/AS before sending the NOTIFY requests. 

A. 6. 4 MRFC/AS drops a user from a conference 
A.6.4.1 MRFC/AS is located in user's inome network 

Figure A.6.4.1-1 shows an MRFC/AS dropping a user from a conference. 
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Figure A.6.4.1-1 : MRFC/AS dropping a user from a conference 

The details of the flows are as follows. 

1. BYE (MRFC/AS to S-CSCF) - see example in table A.6.4.1-1 

MRFC/AS decides to drop a user from a conference. The decision may be based on a change in the 
conference policy, because the conference lifetime is exceeded, or some other reason. 

The MRFC/AS issues a BYE request to the S-CSCF. 

Table A.6.4.1-1 : BYE (IVIRFC/AS to S-CSCF) 



BYE sipiuserl publiclohomel . net ;gr 


=urn 


uuid: f 81d4fae-7dec- 


lldO- 


a765 


-00a0c91e 


6bfS 


;comp=sigcomp SIP/2.0 


















Via: SIP/2. 0/UDP mrfcl.homel 


net ;b 


ranch=z9hG4bK348923 . 1 












Max- Forwards : 7 


















Route: <sip : scscf 1 .homel .net 


-lr>, 


<sip 


pcscf 1 . visitedl .net 


;lr> 










From: <sip : conf erencelomrf cl 


homel 


.net>; tag=314159 












To: <sip:userl publiciohomel 


net>; 


tag= 


=171828 












Call -ID: Cb03a0s09a2sdfglkj 490333 
















Cseq: 73 BYE 


















Content-Length: 



















Request-URI: contains the Contact address of the dropped user. 
2. BYE (S-CSCF to P-CSCF) - see example in table A.6.4.1-2 

The S-CSCF forwards the BYE request to the P-CSCF. 
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Table A.6.4.1-2: BYE (S-CSCF to P-CSCF) 



BYE sip: [5555 : :aaa:bbb:ccc :ddd] : 1357; comp = sigcomp SIP/2.0 




Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , 


SIP/2. 0/UDP 


mrfcl .homel .net ;branch=z9hG4bK348923 . 1 




Max-Forwards: 69 




Route : <sip :pcscf 1 . visitedl .net; lr> 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





3. Remove resource reservation 

The P-CSCF removes the authorization for resources that had previously been issued for this endpoint for 
this session. This step will also result in a release indication to the GPRS subsystem to confirm that the IP 
bearers associated with the session have been deleted. 

4. BYE (P-CSCF to UE) - see example in table A.6.4.1-4 

The P-CSCF forwards the BYE to the UE. 

Table A.6.4.1-4: BYE (P-CSCF to UE) 



BYE sip: [5555 : :aaa:bbb:ccc :ddd] : 1357;comp = sigcomp SIP/2.0 




Via: SIP/2. 0/UDP pcscfl .visitedl . net ;branch=z9hG4bK240f 34 . 1 , 


SIP/2. 0/UDP 


scscf 1. homel. net ;branch=z9hG4bK332b23.1, SIP/2. 0/UDP 




mrfcl .homel .net ;branch=z9hG4bK348923 . 1 




Max-Forwards: 68 




From: 




To: 




Call-ID: 




Cseq: 




Content-Length: 





5. 200 (OK) response (UE to P-CSCF) - see example in table A.6.4.1-5 

After successfully releasing the resources from the MRFP, the MRFC/AS sends a 200 (OK) response to the 
S-CSCF. 

Table A.6.4.1-5: 200 (OK) response (UE to P-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP pcscf 1. visitedl. net;branch=z9hG4bK240f 34 .1, SIP/2 . 0/UDP 

scscf 1. homel. net ;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK348923 . 1 
P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length: 



6. 200 (OK) response (P-CSCF to S-CSCF) - see example in table A.6.4.1-6 

P-CSCF forwards the 200 (OK) response to the S-CSCF. 
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Table A.6.4.1-6: 200 (OK) response (P-CSCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP scscf 1 . homel . net ;branch=z9hG4bK332b23 . 1 , SIP/2. 0/UDP 

mrfcl .homel .net ;branch=z9hG4bK348923 . 1 
P-Access-Network-Info : 
From: 
To: 

Call-ID: 
Cseq: 
Content-Length : 



7. 200 (OK) response (S-CSCF to MRFC/AS) - see example in table A.6.4.1-7 
S-CSCF forwards the 200 (OK) response to the MRFC/AS. 

Table A.6.4.1-7: 200 (OK) response (S-CSCF to MRFC/AS) 



SIP/2.0 200 OK 
Via: SIP/2. 0/UDP 


mrfcl 


homel 


net 


branch= 


z9hG4bK348923 


1 


P-AccesE 


-Network- 


Info: 












From: 
















To: 
















Call-ID 
















Cseq: 
Content - 


Length: 















8. H.248 interaction to release resources 

MRFC/AS interacts with the MRFP to release the resources reserved for UE#1 in this conference. 

9. Conference event package messages 

The MRFC/AS also terminates the user's subscription to the conference state event package. The message 
flow is identical to messages 6.5.2.1-9 to 6.5.2.1-15 in subclause 6.5.2.1. for an user leaving a conference. 

A.7 Flows demonstrating conference termination 
A.7.1 General 

The SIP based flows for conference termination look identical to the call flows for a user leaving a conference (see 
subclause A.6.2) / a user being removed from a conference (see subclause A.6.4). The termination of the conference 
itself, after the last user has left / has been removed from the conference does not result in any exchange of SIP 

messages. 

A.8 Flows demonstrating usage of hold and resume 
during conferences 

The hold- and resume-service is already described in 3GPP TS 24.228 [4] and the related call flows can be readily 
applied for the IMS conferencing service. The handling of a conference put on hold by one user is a local matter at the 
MRFC. 
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A.9 Flows demonstrating the use of the Replaces header 
A. 9.1 POTS subscriber invited to a conference 



UE-A 



P-CSCF 



-11.200OK- 
— 12. ACK— 



-15. INVITE- 



-21.200OK- 
—22. ACK— 



-25. REFER- 



-30. NOTIFY - 



-40. NOTIFY - 



-44. BYE- 



-45. 200 OK- 



S-CSCF 



-10. 200OK- 



-13. ACK- 



-16. INVITE- 

-20. 200OK- 

—23. ACK — 
RTP- 



-26. REFER- 



-29. NOTIFY - 



-39. NOTIFY - 



-43. BYE- 



-46. 200 OK- 



AS/MR FC 



MRFP 



-3. INVITE 



-9. 200 OK 



-14. ACK- 



-RTP- 



-17. INVITE- 



-19. 200OK- 



-24. ACK- 



18. H.248 
interaction 



-27. REFER- 
-28. NOTIFY - 



-31.INVITE- 



-32. INVITE 



-35. 200 OK- 
— 36. ACK— 



-34. 200 OKi 



-37. ACK- 



-38. NOTIFY - 



-47. 200 OK 



-■no RTP sent" 

I 



MGCF 



PSTN/ 
ISDN 



MGW 



4. H.248 
interaction 



5. lAM- 



6. Resource 
reservation 



8. H.248 
interaction 



Information 
Channel 



33. H.248 
interaction 



-RTP- 



41 . switching existing 

information channel to 

new RTP session 



Figure A.9-1 : CONF interworking signalling flow in case of an active session between NGN and PSTN 

UE-A is in an active voice session with a PSTN/ISDN TE (SIP dialog with Call-ID, to-tag and from-tag between UE-A 
and MGCF). It then creates a conference and invites the PSTN/ISDN TE to the conference by sending a REFER to the 
conference focus, which invites the PSTN/ISDN TE to the conference by sending an INVITE which includes the 
Replaces header to the MGCF. The MGCF confirms the session, switches the existing information channel to the new 
RTP session, and terminates the session which is replaced. 
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NOTE: The example given in the figure above assumes that the INVITE request sent from the UE and the 
INVITE request sent from the AS/MRFC are routed to the same MGCP. 



1.-3. UE-A initiates a voice session with a PSTN/ISDN TE by sending an INVITE to the MGCF. 

Table A.9-1 : 1 .INVITE (UE-A to P-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip ipcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip:scscfl .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=17182 8 

To: <tel:+l-212-555-2222> 

Call -ID: Cb03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c = 98765432 ; spi -s =8765432 1 ; port- 

c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net ;gr=urn:uuid: f 81d4f ae-7dec-lld0-a765-0 0a0c91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE 
Accept : application/sdp, application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o=- 2987933615 2987933615 IN IP6 5555 : : aaa :bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



NOTE: Intermediate steps (183 (Session Progress), PRACK, UPDATE and releated responses are not shown) 

4. H.248 interaction 

5. SS7: lAM 

6. resource reservation 

7. SS7: ANM 

8. H.248 interaction 

9. - 11. The MGCF sends a final response back to the session originator. 
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Table A.9-2: 9. 200 OK (MGCF to S-CSCF) 



SIP/2.0 200 OK 

Via: SIP/2. 0/UDP bgcf 1 .homel .net ;branch=z9hG4bK6546q2 . 1, SIP/2. 0/UDP 
scscf 1 .homel .net;branch=z9hG4bK332b23 .1, SIP/2 . 0/UDP 
pcscfl. homel. net ;branch=z9hG4bK431h23 .1, SIP/2 .0/UDP 
[5555 : :aaa:bbb:ccc:ddd] : 1357;comp=sigcomp;branch=z9hG4bKnashds7 

Record- Route : <sip:scscfl .homel .net; lr>, <sip: pcscfl .homel .net; lr> 

P- Asserted- Identity: <tel : +1-212 -555 -2222 > 

P-Charging-Vector : 

Privacy: none 

From: 

To: <tel: +1-212 -555 -2222 >;tag=314159 

Call-ID: 

CSeq: 

Contact: <sip :mgcfl .homel .net> 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE 

RSeq: 9021 

Content-Length: 



12. - 14. The Calling party acknowledges the final response with an ACK request. 

15. - 24. UE-A creates a conference by sending an INVITE to the Conference URI and connects to the conference. 

Table A.9-3: 15. INVITE request (UE-A to P-CSCF) 



INVITE sip : conference- factorylOmrfcl .homel .net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : :aaa:bbb:ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max- Forwards : 7 

Route : <sip : pcscfl . visitedl .net : 7531; lr;comp=sigcomp>, <sip :orig@scscf 1 .homel .net ; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel .net>; tag=171829 

To : <sip : conference- factorylOmrfcl .homel .net> 

Call -ID: Cb03a0s09a2sdfglkj 490444 

Cseq: 127 INVITE 

Require: sec-agree 

Proxy-Require: sec-agree 

Supported: precondition, lOOrel, gruu, 199 

Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=98765432 ; spi-s=87654321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY 
Accept : application/sdp, . application/3gpp-ims+xml 
Content-Type: application/sdp 
Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : aaa : bbb : ccc : ddd 

s = - 

c=IN IP6 5555 :: aaa: bbb: CCC: ddd 

t = 

m=video 34 RTP/AVP 98 99 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

a=rtpmap:99 MPVMP4V-ES 

m=audio 3456 RTP/AVP 97 96 

b=AS:2 5.4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7 ; maxframes=2 

a=rtpmap:96 telephone-event 
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NOTE: Intermediate steps (183 (Session Progress), PRACK, UPDATE and releated responses are not shown) 



25. - 27. UE-A invites the PSTN/ISDN TE to the conference by sending a REFER reqest to the conference focus, the 
"method" parameter set to "INVITE". The Refer-To header of the REFER request includes the Replaces parameter with 
Call-ID, to-tag and from-tag from the existing SIP dialog. 



Table A.9-4: 25. REFER request (UE-A to P-CSCF) 



REFER sip: conferencel@mrfcl.homel.net SIP/2.0 

Via: SIP/2. 0/UDP [5555 : : aaa :bbb : ccc :ddd] : 1357 ; comp=sigcomp;branch=z9hG4bKnashds7 

Max-Forwards: 70 

Route : <sip :pcscf 1 . visitedl .net : 7531; lr;comp=sigcomp>, <sip : origOscscf 1 .homel .net; lr> 

P-Pref erred-Identity : "John Doe" <sip :userl_publicl@homel .net> 

P-Access-Network-Info: 3GPP-UTRAN-TDD; utran-cell-id-3gpp=234151D0FCEll 

Privacy: none 

From: <sip :userl_publicl@homel . net> ; tag=171829 

To : <sip : conf erencelomrf cl . homel . net> 

Call -ID: Cb03a0s0 9a2sdfglkj 490555 
Cseq: 127 REFER 
Require: sec-agree 
Refer-To: <sip : +1-212-555- 

2222@homel .net ;user=phone;method=INVITE?Replaces=cb03aOs09a2sdfglkj490333%3Bto-tag%3D 

314159%3Bfrom-tag%3D 171828> 
Referred- By : <sip :userl_publicl@homel .net> 
Proxy-Require: sec-agree 
Security-Verify: ipsec-3gpp; q=0.1; alg=hmac-sha-l-96 ; spi-c=987S5432 ; spi-s=87S54321; 

port-c=8642; port-s=7531 
Contact : <sip :userl_publicl@homel .net; gr=urn:uuid: f 81d4f ae-7dec-lldO-a765-OOaOc91e6bf 6 

;comp=sigcomp> 
Content-Length: 



28. - 30. The conference focus sends a NOTIFY request containing information about the progress of the REFER 
request processing. The Subscription-State is set to "active". 

31. - 32.. The conference focus invites the PSTN/ISDN TE by sending a INVITE request to the MGCF. The INVITE 
request includes the Replaces header with Call-ID, to-tag and from-tag from the existing SIP dialog. 
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Table A.9-5: INVITE request (MRFC/AS to S-CSCF) 



INVITE tel:+l-212-555-2222 SIP/2.0 

Via: SIP/2. 0/UDP mrf cl . homel . net ;branch=z9hG4bK23273846 

Max- Forwards : 7 

P-Asserted- Identity : <sip : conference lOmrfcl .homel .net> 

P-Charging-Vector : icid-value="AyretyU0dm+602IrT5tAFrbHLso=023551024" ; orig-ioi=homel .net 

Privacy: none 

From: <sip : conf erencelOmrf cl .homel .net>; tag=17112 3 

To: <tel: +l-212-555-2222> 

Call -ID: bc03a0s09a2sdfglkj 490333 

Cseq: 127 INVITE 

Require: replaces 

Replaces : cb03a0s09a2sdf glkj 490333 ; to- tag=314159; from- tag=171828 

Supported: precondition, lOOrel, gruu 

Referred- By : <sip :userl_publicl@homel .net> 

Contact : <sip : conf erencelOmrf cl . homel . net> ; isf ocus 

Allow: INVITE, ACK, CANCEL, BYE, PRACK, UPDATE, REFER, MESSAGE, SUBSCRIBE, NOTIFY, PUBLISH 

Allow-Events : conference, pending-additions 

Content-Type: application/sdp 

Content-Length: (...) 

v=0 

o = - 2987933615 2987933615 IN IP6 5555 : : abc : def : abc : abc 

s = - 

c=IN IP6 5555 : :abc:def :abc:def 

t = 

m=video 10001 RTP/AVP 98 

b=AS:75 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:98 H263 

a=fmtp:98 prof ile-level-id=0 

m=audio 6544 RTP/AVP 97 96 

b=AS:25 .4 

a=curr:qos local none 

a=curr:qos remote none 

a=des:qos mandatory local sendrecv 

a=des:qos none remote sendrecv 

a=inactive 

a=rtpmap:97 AMR 

a=fmtp:97 mode-set=0 , 2 , 5 , 7; maxframes=2 

a=rtpmap:96 telephone-event 



NOTE: Intermediate steps (183 (Session Progress), PRACK, UPDATE and releated responses are not shown) 

33. H.248 interaction. 

34. - 35. The MGCP sends a final response back to the session originator. 

36. - 37. The Calling party acknowledges the final response with an ACK request. 

38. - 40. The conference focus sends a NOTIFY request containing information about the progress of the REFER 
request processing. The Subscription-State is set to "terminated". 

41. The MGCF replaces the existing RTP stream to UE-A with the new RTP stream to the conference mixer. 

42. - 44. The MGCF releases the session with UE-A by sending a BYE request to UE-A. 
45. - 47. UE-A responds with a 200 OK response. 
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